Re: [Fwd: Problem with file => 2GB]
Andreas Dilger wrote: > There is a bug in 2.4.2 with the loop device, which is fixed in -ac series. Also fixed in 2.4.3-pre series. cu Jup - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Mounting ISO via Loop Devices
On 20 Mar 2001, Eugene Crosser wrote: > I can confirm that mount over loopback hangs on 2.4.2 (from kernel.org), > regardless of the filesystem type. It seems to have gone away in the 2.4.2-acX series. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] Linux Trace Toolkit version 0.9.4
This new release of the Linux Trace Toolkit includes complete support for Linux and RTAI on both ix86 and PPC. With this out, work on other architectures is in its way. Anyone wanting to dig-in is welcomed to do so. Also, 0.9.4 includes all the additions that were made in the 0.9.4preX series. This includes interfacing with DProbes using dynamic event creation and usage of rvmalloc and friends to avoid having to copy large portions of memory from kernel space to user space. In order to encourage exchanges and discussions, I've set up mailing lists for LTT. Please take a look at the "mailing lists" section of the project's web-site for more detail. You can find LTT at: http://www.opersys.com/LTT Cheers, Karim Yaghmour === Karim Yaghmour [EMAIL PROTECTED] Embedded and Real-Time Linux Expert === - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
timeout waiting for DMA...
Hi all,
I'm seeing the "timeout waiting for DMA" problems that I've noticed
several others are running up against. I have a UDMA-66 drive that I
have _full_ of data. After some amount of disk activity (some can be
very little [a few minutes], or a long time [hours]), I get the
following on the console (copied the best I can):
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hdc: irq timeout: status=0x50 { DriveReady SeekComplete }
hda: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hda: DMA disabled
hdb: DMA disabled
hdc: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hdc: irq timeout: status=0x50 { DriveReady SeekComplete }
ide0: reset timed out, status=0xd0
hdb: status timeout: status=0xd0 { Busy }
hdb: drive not ready for command
hdc: timeout waiting for DMA
The IDE controller in question is a Promise 20262 Ultra/66 controller.
I'd appreciate any suggestions that I can get at this point. I've
spent lots of time building the 2.4.2 kernel, and that didn't seem to
help. I had previously been using the 2.2.17 kernel with the latest
IDE patch from people/hedrick to no avail.
At this point, I'd be more than happy to test out new IDE drivers,
if that's what things take.
Included below is some info from my system. I'm not sure what's
useful, so I probably put more here than I needed to. If there's
something missing, please let me know. Also, I'm not subscribed to
the list, so a CC back to me would be appreciated!
Jason
[EMAIL PROTECTED]
===
[root@excedrin jgillis]# cat /proc/dma
4: cascade
5: GFA1/CS4231 record
7: CS4231 playback
[root@excedrin jgillis]# cat /proc/interrupts
CPU0 CPU1
0: 635966 747681IO-APIC-edge timer
1: 2 0IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
10: 2936 2947 IO-APIC-level ide0, ide1
11: 0 0IO-APIC-edge InterWave
12: 9391 9560 IO-APIC-level eth1
14: 16727 17082 IO-APIC-level eth0
NMI:13835821383582
LOC:13836781383677
ERR: 0
===
[root@excedrin jgillis]# uname -a
Linux excedrin 2.4.2 #1 SMP Sun Mar 18 10:10:31 PST 2001 i686 unknown
===
Stuff from dmesg:
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX3: IDE controller on PCI bus 00 dev 39
PCI: Enabling device 00:07.1 ( -> 0001)
PIIX3: chipset revision 0
PIIX3: not 100% native mode: will probe irqs later
PIIX3: neither IDE port enabled (BIOS)
PDC20262: IDE controller on PCI bus 00 dev 70
PDC20262: chipset revision 1
PDC20262: not 100% native mode: will probe irqs later
PDC20262: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
ide0: BM-DMA at 0xac00-0xac07, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xac08-0xac0f, BIOS settings: hdc:DMA, hdd:pio
hda: FUJITSU M1623TAU, ATA DISK drive
hdb: Maxtor 86480D6, ATA DISK drive
hdc: WDC WD450AA, ATA DISK drive
ide0 at 0x9c00-0x9c07,0xa002 on irq 10
ide1 at 0xa400-0xa407,0xa802 on irq 10
hda: 3324996 sectors (1702 MB) w/128KiB Cache, CHS=3298/16/63, DMA
hdb: 12594960 sectors (6449 MB) w/256KiB Cache, CHS=13328/15/63, UDMA(33)
hdc: 87930864 sectors (45021 MB) w/2048KiB Cache, CHS=87233/16/63, UDMA(66)
Partition check:
hda: [PTBL] [824/64/63] hda1 hda2
hdb: [PTBL] [784/255/63] hdb1
hdc: [PTBL] [5473/255/63] hdc1
===
[root@excedrin jgillis]# cat /proc/pci
...
Bus 0, device 14, function 0:
Unknown mass storage controller: Promise Technology, Inc. 20262 (rev 1).
IRQ 10.
Master Capable. Latency=64.
I/O at 0x9c00 [0x9c07].
I/O at 0xa000 [0xa003].
I/O at 0xa400 [0xa407].
I/O at 0xa800 [0xa803].
I/O at 0xac00 [0xac3f].
Non-prefetchable 32 bit memory at 0xe200 [0xe201].
===
[root@excedrin jgillis]# /sbin/hdparm -i /dev/hda
/dev/hda:
Model=FUJITSU M1623TAU, FwRev=5243, SerialNo=2003
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=3298/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=0(?), BuffSize=128kB, MaxMultSect=16, MultSect=off
DblWordIO=no, maxPIO=2(fast), DMA=yes, maxDMA=2(fast)
CurCHS=3298/16/63, CurSects=-117650, LBA=yes
LBA CHS=824/64/63 Remapping, LBA=yes, LBAsects=3324996
tDMA={min:120,rec:120}, DMA modes: sword0 sword1 sword2 mword0 mword1
*mword2
IORDY=yes, tPIO={min:240,w/IORDY:120}, PIO modes: mode3 mode4
[root@excedrin jgillis]# /sbin/hdparm -i /dev/hdb
/dev/hdb:
Model=Maxtor 86480D6, FwRev=NAVX171F, SerialNo=L6066EZA
Config={ Fixed }
RawCHS=13328/15/63, TrkSize=0, SectSize=0, ECCbytes=20
BuffType=3(DualPortCache), BuffSize=256kB, MaxMultSect=16, MultSect=off
DblWordIO=no, maxPIO=2(fast), DMA=yes, maxDMA=2(fast)
CurCHS=13328/15/63, CurSects=789577920, LBA=yes
LBA CHS=784/255/63
Re: Mounting ISO via Loop Devices
In article <[EMAIL PROTECTED]>, "Brent D. Norris" <[EMAIL PROTECTED]> writes: > On my redhat 7.1 machine I have been using the 2.4.0 redhat kernel and > mounting ISO's to loop devices and it worked fine. I upgraded to a 2.4.2 > kernel and now none of the ISO's will mount. They all hang when the > command is run. Are there any other known occurences of this? I can confirm that mount over loopback hangs on 2.4.2 (from kernel.org), regardless of the filesystem type. Eugene - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3rd version of R/W mmap_sem patch available
On Tue, 20 Mar 2001, Marcelo Tosatti wrote: > > I'll put pre5 in and try to reproduce the problem (I hitted it while > running pgbench + shmtest). I found a case where pre5 will forget to unlock the page_table_lock (in copy_page_range()), and one place where I had missed the lock altogether (in ioremap()), so I'll make a pre6 (neither is a problem on UP, though, so pre5 is not unusable - even on SMP it works really well until you hit the case where it forgets to unlock ;). Although I'd prefer to see somebody check out the other architectures, to do the (pretty trivial) changes to make them support properly threaded page faults. I'd hate to have two pre-patches without any input from other architectures.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3rd version of R/W mmap_sem patch available
On Tue, 20 Mar 2001, Marcelo Tosatti wrote: > > Could the IDE one cause corruption ? Only with broken disks, as far as we know right now. There's been so far just one report of this problem, and nobody has heard back about which disk this was.. And it should be noisy about it when it happens - complaining about lost interrupts and resetting the IDE controller. So unlikely. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3rd version of R/W mmap_sem patch available
On Mon, 19 Mar 2001, Linus Torvalds wrote: > > > On Tue, 20 Mar 2001, Marcelo Tosatti wrote: > > > > Could the IDE one cause corruption ? > > Only with broken disks, as far as we know right now. There's been so far > just one report of this problem, and nobody has heard back about which > disk this was.. And it should be noisy about it when it happens - > complaining about lost interrupts and resetting the IDE controller. > > So unlikely. Ok, so I think we have a problem. The disk is OK -- no lost interrupts or resets. Just this message on syslog and pgbench complaining about corruption of the database. I'll put pre5 in and try to reproduce the problem (I hitted it while running pgbench + shmtest). Damn. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3rd version of R/W mmap_sem patch available
On Mon, 19 Mar 2001, Linus Torvalds wrote: > > There is a 2.4.3-pre5 in the test-directory on ftp.kernel.org. > > The complete changelog is appended, but the biggest recent change is the > mmap_sem change, which I updated with new locking rules for pte/pmd_alloc > to avoid the race on the actual page table build. > > This has only been tested on i386 without PAE, and is known to break other > architectures. Ingo, mind checking what PAE needs? Generally, the changes > are simple, and really only implies changing the pte/pmd allocation > functions to _only_ allocate (ie removing the stuff that actually modifies > the page tables, as that is now handled by generic code), and to make sure > that the "pgd/pmd_populate()" functions do the right thing. > > I have also removed the xxx_kernel() functions - for architectures that > need them, I suspect that the right approach is to just make the > "populate" funtions notice when "mm" is "init_mm", the kernel context. > That removed a lot of duplicate code that had little good reason. > > This pre-release is meant mainly as a synchronization point for mm > developers, not for generic use. > > Thanks, > > Linus > > > - > -pre5: > - Rik van Riel and others: mm rw-semaphore (ps/top ok when swapping) > - IDE: 256 sectors at a time is legal, but apparently confuses some > drives. Max out at 255 sectors instead. Could the IDE one cause corruption ? EXT2-fs error (device ide0(3,1)): ext2_free_blocks: bit already cleared for block 6211 Just hitted this now with pre3. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] 16 potential locking bugs in 2.4.1
On Friday March 16, [EMAIL PROTECTED] wrote: > Here are some more results from the MC project. These are 16 errors found > in 2.4.1 related to inconsistent use of locks. As usual, if you can > verify any of these or show that they are false positives, please let us > know by CC'ing [EMAIL PROTECTED] > > -Andy Chou > > | fs/nfsd/vfs.c | nfsd_link | > | fs/nfsd/vfs.c | nfsd_symlink | These are not actually bugs. The usage of fh_lock is fairly obscure. The unlock gets done by an fh_put which the caller does after calling nfsd_link or nfs_symlink. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Jiffy question and sound.
watermodem wrote:
>
> Matti Aarnio wrote:
> >
> > On Mon, Mar 19, 2001 at 12:20:47AM -0600, watermodem wrote:
> > > With the 2.4.0 kernel the loops_per_sec field was replaced (for i386)
> > > with current_cpu_data.loops_per_jiffy.
> > ...
> > > #define LOOPS_PER_SEC current_cpu_data.loops_per_jiffy * 100
> >
> > The intention was to accomodate systems with faster than 2 GHz clock
> > at which the LOOPS_PER_SEC counter spins around a bit too fast..
> > ('signed long' at i386 handles 0..2G just fine, then it thinks the sign
> >got inverted.. 'unsigned long' works fine until 4 GHz processors.)
> >
>
> My sound card uses ALSA and ALSA wasn't available yet for
> the new kernel. So.. Noting that LOOPS_PER_SEC was what
> failed in the kernel I modified it and compiled. I am
> not associated in anyway with the ALSA folks just wanted
> too listen to music while working away. I have no idea
> why it needs it or if it is busy-looping... (I hope not).
I noticed that if I kill the "artsd" daemon and then
let it naturally restart when starting another music player
the problem goes away for awhile. When artsd starts using
more than 1.7% of the CPU then the problem occurs. So I think
I was looking at the wrong code. Perhaps the problem is with
the daemon.
>
> > Why does the ALSA need LOOPS_PER_SEC ?
> > Is it doing timing by busy-looping ?
> >
> > > Now compiling the same ALSA modules with 2.4.2 this problem happens
> > > much quicker and you don't need any other activity. In fact it is hard
> > > to play more than half a song. (MP3)
> > > It doesn't matter if what set of music players or tools I use the
> > > problem is quite visible.
> > >
> > > When I boot back to the original 2.2.x kernel everything is perfect.
> > >
> > > So I guess I have a few questions here.
> > > 1) Is a jiffy 100th of a second or is it smaller (so my loop count
> > > is starving things.) (10ms) ?
> >
> > "HZ" is the answer. E.g. Alpha has HZ=1024, while i386 has HZ=100
> > Nearly all architectures have different values based on what some
> > other UNIX uses at given system.
> >
> > > 2) Why is it so much worse in 2.4.2 than 2.4.0?
> > > 3) Any other "gotch's" that are important to watch for when moving
> > > 2.2.x drivers to 2.4.x?
> >
> > The FAQ may have some pointers to "porting drivers to 2.4" documents.
> >
> > > Thanks
> > > Watermodem
> > > -
> > > Please read the FAQ at http://www.tux.org/lkml/
> >
> > /Matti Aarnio
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3rd version of R/W mmap_sem patch available
On Tue, 20 Mar 2001, Rik van Riel wrote: > > (ie the patch really isn't ready yet to be included in the > main kernel ... OTOH, the changes needed to make it ready > are all trivial and tedious ;)) They are trivial and tedious only if done wrong - which will also add tons of new places where we lock and unlock only to lock again. My -pre5 has the non-trivial "fix the calling convention and require that pmd/pgd_alloc() be called with the lock held" version of the patch. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3rd version of R/W mmap_sem patch available
On Mon, 19 Mar 2001, Linus Torvalds wrote: > On Mon, 19 Mar 2001, Linus Torvalds wrote: > > > > Excellent point. We used to do all the looping and re-trying, but it got > > ripped out a long time ago (and in any case, it historically didn't do > > SMP, so the old code doesn't really work). > > Actually, funnily enough, I see that the old thread-safe stuff is still > there in get_pte_kernel_slow(). The only thing that breaks it is that we > don't hold any locks, so it's only UP-safe, not SMP-safe. > > However, it definitely looks like we should just un-inline that thing > completely, and make a lot of it architecture-independent anyway. Also, because lots of architectures seem to have exactly the same code, we might as well remove the duplicates and put them in the same place... regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.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: 3rd version of R/W mmap_sem patch available
On Tue, 20 Mar 2001, Manfred Spraul wrote:
> >
> > Besides, the fair semaphores would potentially slow things down, while
> > this potentially speeds things up. So.. It looks obvious enough.
>
> Rik, did you check that {pte,pmd}_alloc are thread safe? At
> least in 2.4.2 they aren't (include/asm-i386/pgalloc.h), and
> your patch doesn't touch pgalloc.
I checked and they're not. This still needs to be fixed...
(ie the patch really isn't ready yet to be included in the
main kernel ... OTOH, the changes needed to make it ready
are all trivial and tedious ;))
regards,
Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.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: Jiffy question and sound.
Matti Aarnio wrote:
>
> On Mon, Mar 19, 2001 at 12:20:47AM -0600, watermodem wrote:
> > With the 2.4.0 kernel the loops_per_sec field was replaced (for i386)
> > with current_cpu_data.loops_per_jiffy.
> ...
> > #define LOOPS_PER_SEC current_cpu_data.loops_per_jiffy * 100
>
> The intention was to accomodate systems with faster than 2 GHz clock
> at which the LOOPS_PER_SEC counter spins around a bit too fast..
> ('signed long' at i386 handles 0..2G just fine, then it thinks the sign
>got inverted.. 'unsigned long' works fine until 4 GHz processors.)
>
My sound card uses ALSA and ALSA wasn't available yet for
the new kernel. So.. Noting that LOOPS_PER_SEC was what
failed in the kernel I modified it and compiled. I am
not associated in anyway with the ALSA folks just wanted
too listen to music while working away. I have no idea
why it needs it or if it is busy-looping... (I hope not).
> Why does the ALSA need LOOPS_PER_SEC ?
> Is it doing timing by busy-looping ?
>
> > Now compiling the same ALSA modules with 2.4.2 this problem happens
> > much quicker and you don't need any other activity. In fact it is hard
> > to play more than half a song. (MP3)
> > It doesn't matter if what set of music players or tools I use the
> > problem is quite visible.
> >
> > When I boot back to the original 2.2.x kernel everything is perfect.
> >
> > So I guess I have a few questions here.
> > 1) Is a jiffy 100th of a second or is it smaller (so my loop count
> > is starving things.) (10ms) ?
>
> "HZ" is the answer. E.g. Alpha has HZ=1024, while i386 has HZ=100
> Nearly all architectures have different values based on what some
> other UNIX uses at given system.
>
> > 2) Why is it so much worse in 2.4.2 than 2.4.0?
> > 3) Any other "gotch's" that are important to watch for when moving
> > 2.2.x drivers to 2.4.x?
>
> The FAQ may have some pointers to "porting drivers to 2.4" documents.
>
> > Thanks
> > Watermodem
> > -
> > Please read the FAQ at http://www.tux.org/lkml/
>
> /Matti Aarnio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: user space web server accelerator support
Fabio Riccardi writes: > How can Apache "grab" the file descriptor? > > My understanding is that file descriptors are data structures private to > a process... > > Am I missing something? Unix sockets allow one processes to "give" a file descriptor to another process via a facility called "file descriptor passing". Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.4.2-ac20] trivial - de4x5 driver - stops the oops on AlphaXP1000's
diff -urN linux-2.4.2-ac20-orig/drivers/net/de4x5.c linux-2.4.2-ac20/drivers/net/de4x5.c --- linux-2.4.2-ac20-orig/drivers/net/de4x5.c Mon Mar 19 17:24:04 2001 +++ linux-2.4.2-ac20/drivers/net/de4x5.cMon Mar 19 18:32:01 2001 @@ -429,11 +429,17 @@ <[EMAIL PROTECTED]> Remove double checking for DEBUG_RX in de4x5_dbg_rx() from report by <[EMAIL PROTECTED]> - + 0.546 22-Feb-01Fixes Alpha XP1000 oops. The srom_search function + was causing a page fault when initializing the + variable 'pb', on a non de4x5 PCI device, in this + case a PCI bridge (DEC chip 21152). The value of + 'pb' is now only initialized if a de4x5 chip is + present. + <[EMAIL PROTECTED]> = */ -static const char *version = "de4x5.c:V0.545 1999/11/28 [EMAIL PROTECTED]\n"; +static const char *version = "de4x5.c:V0.546 2001/02/22 [EMAIL PROTECTED]\n"; #include #include @@ -2304,12 +2310,12 @@ /* Skip the pci_bus list entry */ if (list_entry(walk, struct pci_bus, devices) == dev->bus) continue; - pb = this_dev->bus->number; vendor = this_dev->vendor; device = this_dev->device << 8; if (!(is_DC21040 || is_DC21041 || is_DC21140 || is_DC2114x)) continue; /* Get the chip configuration revision register */ + pb = this_dev->bus->number; pcibios_read_config_dword(pb, this_dev->devfn, PCI_REVISION_ID, &cfrv); /* Set the device number information */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: user space web server accelerator support
Fantastic! I was not aware of it, sorry... where can I find some doc? - Fabio "David S. Miller" wrote: > Fabio Riccardi writes: > > How can Apache "grab" the file descriptor? > > > > My understanding is that file descriptors are data structures private to > > a process... > > > > Am I missing something? > > Unix sockets allow one processes to "give" a file descriptor to > another process via a facility called "file descriptor passing". > > Later, > David S. Miller > [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: user space web server accelerator support
Fabio Riccardi writes: > How could this be fixed? Why not pass the filedescriptors to apache over a UNIX domain socket? I see no need for a new facility. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: user space web server accelerator support
How can Apache "grab" the file descriptor? My understanding is that file descriptors are data structures private to a process... Am I missing something? - Fabio "David S. Miller" wrote: > Fabio Riccardi writes: > > How could this be fixed? > > Why not pass the filedescriptors to apache over a UNIX domain > socket? I see no need for a new facility. > > Later, > David S. Miller > [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
user space web server accelerator support
Hi, I've been working for a while on a user-space web server accelerator (as opposed to a kernel space accelerator, like TUX). So far I've had very promising results and I can achieve performance (spec) figures comparable to those of TUX. Although my implementation is entirely sitting in user space, I need some cooperation form the kernel for efficiently forwarding network connections from the accelerator to the full-fledged Apache server. I've made a little kernel hack (mostly lifted out of the TUX and khttpd code) to forward a live socket connection from an application to another. I'd like to clean this up such that my users don't have to mock with their kernel to get my accelerator to work. Would it be a major heresy to ask for a new system call? If so I could still hide my stuff in a kernel module and snatch an unused kernel call for my private use (such as the one allotted for tux). The problem with this is that the kernel only exposes the "right" symbols to the modules if either khttp or ipv6 are compiled as modules. How could this be fixed? TIA, ciao, - Fabio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
gcc-3.0 and abs
usb audio uses the abs function, which is no longer included in gcc-3.0 Not a big deal yet, since the kernel crashes with it anyway, but something to look at. Garst - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3rd version of R/W mmap_sem patch available
On Tue, 20 Mar 2001, Andrew Morton wrote: > Linus Torvalds wrote: > > > > There is a 2.4.3-pre5 in the test-directory on ftp.kernel.org. > > I can't see it. Where did you hide it? Ahh. The mirroring is apparently broken. I put my stuff on a faster local connection to "master.kernel.org", and depend on it being mirrored automatically. And apparently the mirroring has been down for a few days now. Ugh. I'll ping Peter. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: atyfb,matrox hardlocks, multihead, USB broken, 2.4.2-ac8
Elmer Joandi wrote: > ah - message from matrox framebuffer - complaining no irq A assigned to > slot, and suggesting that BIOS is buggy. Maybe you disabled it in BIOS? My BIOS has option 'assign irq to vga'... > Will I be more happy when using a dualhead matrox AGP instead of AGP+PCI > ATI pair ? It depends on how much heads you need. If you want more than one head and all heads need full acceleration, do not go to G400/G450. There is only one accelerator on them... (well, if you are using all displays together as one big workplace, you can try it; in that case it has benefit that both heads share same memory, so you can save some intersection operations). > 2.4.0 kernel, 2.4.2-ac8 USB looks like very very broken. USB worked for me until about 2.4.2-ac12 (VIA chipset). Petr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: atyfb,matrox hardlocks, multihead, USB broken, 2.4.2-ac8
Got it to work somewhat... that was real long f*** the only sequence - no dga, kernel boots and BIOS uses Matrox PCI as first graphics via matrox start up two ATI cards(one AGP, one PCI)(xinerama mode, screwed output ) with Xserver hacked to read /dev/input/event* ant talking direct to ATI. now insert matroxfb_base now start two normal XFree86 on framebuffer /dev/fb0 and /dev/fb1, i.e. matroxes, xinerama keyboard from system console... log into matroxes ATI dualscreen picture clears itself by magic spell and becomes usable. everything works... until ATI exits, then there is kernel hardlock. Weird that all locks are hardlocks - no ping no sysreq... SMP here. ah - message from matrox framebuffer - complaining no irq A assigned to slot, and suggesting that BIOS is buggy. Will I be more happy when using a dualhead matrox AGP instead of AGP+PCI ATI pair ? 2.4.0 kernel, 2.4.2-ac8 USB looks like very very broken. elmer. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
code region
Dear friends: I have a question about memory protection. I appreciate any suggestion. Thank you so much. Given a virtual address, how can we know whether this address contains an executable code? If there is a method that can be used to answer the above question, is there any exception for this method? PS: (a)Could we get the result by checking the VM_EXECUTABLE attribute of the vm_flags of the vm_area_struct for the memory area that contains that address? If yes, does this apply to x86 architecture? (b) Could information in vm_page_prot of vm_area_struct or in struct mem_map_t help? If yes, which attribute and how? Best Regards, FuHau - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3rd version of R/W mmap_sem patch available
There is a 2.4.3-pre5 in the test-directory on ftp.kernel.org. The complete changelog is appended, but the biggest recent change is the mmap_sem change, which I updated with new locking rules for pte/pmd_alloc to avoid the race on the actual page table build. This has only been tested on i386 without PAE, and is known to break other architectures. Ingo, mind checking what PAE needs? Generally, the changes are simple, and really only implies changing the pte/pmd allocation functions to _only_ allocate (ie removing the stuff that actually modifies the page tables, as that is now handled by generic code), and to make sure that the "pgd/pmd_populate()" functions do the right thing. I have also removed the xxx_kernel() functions - for architectures that need them, I suspect that the right approach is to just make the "populate" funtions notice when "mm" is "init_mm", the kernel context. That removed a lot of duplicate code that had little good reason. This pre-release is meant mainly as a synchronization point for mm developers, not for generic use. Thanks, Linus - -pre5: - Rik van Riel and others: mm rw-semaphore (ps/top ok when swapping) - IDE: 256 sectors at a time is legal, but apparently confuses some drives. Max out at 255 sectors instead. - Petko Manolov: USB pegasus driver update - make the boottime memory map printout at least almost readable. - USB driver updates - pte_alloc()/pmd_alloc() need page_table_lock. -pre4: - Petr Vandrovec, Al Viro: dentry revalidation fixes - Stephen Tweedie / Manfred Spraul: kswapd and ptrace race - Neil Brown: nfsd/rpc/raid cleanups and fixes -pre3: - Alan Cox: continued merging - Urban Widmark: smbfs fix (d_add on already hashed dentry - no-no). - Andrew Morton: 3c59x update - Jeff Garzik: network driver cleanups and fixes - Gérard Roudier: sym-ncr drivers update - Jens Axboe: more loop cleanups and fixes - David Miller: sparc update, some networking fixes -pre2: - Jens Axboe: fix loop device deadlocks - Greg KH: USB updates - Alan Cox: continued merging - Tim Waugh: parport and documentation updates - Cort Dougan: PowerPC merge - Jeff Garzik: network driver updates - Justin Gibbs: new and much improved aic7xxx driver 6.1.5 -pre1: - Chris Mason: reiserfs, another null bytes bug - Andrea Arkangeli: make SMP Athlon build - Alexander Zarochentcev: reiserfs directory fsync SMP locking fix - Jeff Garzik: PCI network driver updates - Alan Cox: continue merging - Ingo Molnar: fix RAID AUTORUN ioctl, scheduling improvements - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sysrq.txt
> > Well, as there is no keyboard combo that works on every Mac, I think we should >> list every known to be working combo. >> >> Like: >> >> On PowerPC - Press 'ALT - Print Screen (or F13) - , >> Print Screen (or F13) - may suffice. > >Sounds good. > >> Maybe it's a good idea to include F13's keycode, which I don't know. > >Nah. I think we should try and fix this sometime tho. Perhaps the round >powerbutton on the keyboard could do 'F13' (and add this to the list..) FWIW, the F9 key on a G3 PowerBook is labeled "prt screen", and you get that function with the "fn" key, not the "alt" key (which is a secondary label on the "opt" key). -- /Jonathan Lundell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: Problem with file => 2GB]
"Fabio Pietrosanti (naif)" wrote: > > i'm currently involved in the analisys of a compromised linux box. > > It was a IBM xSeries server. > > > > I transfer the partition of the server using cat /dev/partition| nc > > host_of_dump_storage 8889, then i check the checksum using md5sum and > > all it's ok. > > > > There are 2 partition dump of 8GB . > > So i have to mount another 30GB hd, i installed Linux Kernel 2.4.2 with > > the 30gb on reiserfs . > > I recompiled all fileutils, util-linux and bin-utils with kernel 2.4.2 > > and the define for => 2GB file support . > > > > Ok, now i could download the partition, i could ls, more, strings the > > partition, but i need to use it as loop device!! > > > > When i mount the partition as loop device the mount command HANG on read() > > function... it seems that loop device under linux didn't work against => 2gb > > files ? There is a bug in 2.4.2 with the loop device, which is fixed in -ac series. Also, I don't think it is possible to use > 2GB for loop (or at least that used to be the case). Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: About DC-315U scsi driver
On Mon, 19 Mar 2001 19:30:49 +0100 (CET) Pierre Etchemaite <[EMAIL PROTECTED]> wrote: > FYI, burning CDRs with this adapter seldom work under Windows too, Tekram > adapters are usually fine, but those DC-315* & DC-395* really look like chip > stuff... > > BR, > Pierre. > > I never have errors under MS-windows with VIA bridge chip. It's a problem for me,when I start to use kernel 2.4.x. The timing between the new SCSI layer and the Hardware of DC-315 has some mismatch.(I guess it) Maybe at sometimes,I would not like waiting a specific driver for it. What's the best choice of SCSI card which support won't have errors and the linux kernel won't give up supporting it??? Best Regards,cwz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sysrq.txt
On Tue, Mar 20, 2001 at 02:07:13AM +0100, J. Michael Kolbe wrote: [snip] > Well, as there is no keyboard combo that works on every Mac, I think we should > list every known to be working combo. > > Like: > > On PowerPC - Press 'ALT - Print Screen (or F13) - , > Print Screen (or F13) - may suffice. Sounds good. > Maybe it's a good idea to include F13's keycode, which I don't know. Nah. I think we should try and fix this sometime tho. Perhaps the round powerbutton on the keyboard could do 'F13' (and add this to the list..) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Trident sound driver - global registers not restored
Hello! The driver for Trident sound cards in 2.4.2-ac20 has functions ali_save_regs() and ali_restore_regs() that are supposed to save and restore the hardware registers over the power management events. ali_restore_regs() restores mixer and channel registers from memory, but it _saves_ the global registers instead of restoring them: ali_registers.global_regs[i] = inl(TRID_REG(card, i*4)); It must be an error (most likely a result of cut-and-paste). Regards, Pavel Roskin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
promise fasttrak ide raid on linux 2.4 in the future?
i have the source files for compiling the module for 2.2 kernels but i can't get it to work in 2.4 is anyone programming a 2.4 driver/module ? 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: KMALLOC_MAXSIZE undeclared in drivers/media/video/buz.c
grab my KMALLOC_MAXSIZE patch from this posting http://marc.theaimsgroup.com/?l=linux-kernel&m=98398907520444&w=2 Joseph Cheek wrote: > > 2.4.3-pre4. > > i also see a reference to KMALLOC_MAXSIZE in > drivers/net/hamradio/6pack.c > > this kernel won't compile, is KMALLOC_MAXSIZE set somewhere? i can't > find it. is it deprecated? -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Fwd: Problem with file => 2GB]
This is forwarded from the [EMAIL PROTECTED] mailing list. I think you guys can answer this question better. Please cc: them in any replies. -b "Fabio Pietrosanti (naif)" wrote: > Hi ppl, > i'm currently involved in the analisys of a compromised linux box. > It was a IBM xSeries server. > > I transfer the partition of the server using cat /dev/partition| nc > host_of_dump_storage 8889, then i check the checksum using md5sum and all it's > ok. > > Where's the problem? > > There are 2 partition dump of 8GB . > So i have to mount another 30GB hd, i installed Linux Kernel 2.4.2 with the > 30gb on reiserfs . > I recompiled all fileutils, util-linux and bin-utils with kernel 2.4.2 and the > define for => 2GB file support . > > Ok, now i could download the partition, i could ls, more, strings the > partition, but i need to use it as loop device!! > > When i mount the partition as loop device the mount command HANG on read() > function... it seems that loop device under linux didn't work against => 2gb > files ? > > Any solutions? > > Best Regards > > -- > Pietrosanti Fabio I.NET SpA, High Quality Access to the Internet > e-mail: [EMAIL PROTECTED] ( Direzione Tecnica, Security Staff ) > [EMAIL PROTECTED] > PGP Key (DSS) http://naif.itapac.net/naif.asc > > Home Page URL:http://www.inet.it > Sede: Via Darwin, 85 20019 Settimo Milanese (MI) > Tel: 02-328631 Fax: 02-328637701 > -- > Free advertising: www.openbsd.org - Multiplatform Ultra-secure OS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sysrq.txt
On Tue, Mar 20, 2001 at 01:00:53AM +0100, J. Michael Kolbe wrote: > Hi. > > On Mon, Mar 19, 2001 at 04:21:35PM -0700, Tom Rini wrote: > > On Mon, Mar 19, 2001 at 11:14:03PM +, Andrew Morton wrote: > > > > > I included Mr Kolbe's one-liner in the SAK patch which I put > > > out on Sunday. Now my head is spinning. > > > > > > What *should* the change to sysrq.txt say? > > > > Well, I think: > > > > On PowerPC - You press 'ALT-Print Screen (or F13)- > > > > Which is what 2.2 says, but mentions F13 directly (incase print screen isn't > > on the key.). The above even makes sense for 2 of my machines which have > > working sysrq and keyboards. > > Well, I've just found an old USB Keyboard, none of the mentioned > Keyboard combos work, as there is neither F13 nor PrintScreen. Yes, as SysRq quite possibly doesn't work on (since none of the keys on it send the right keycode.) > > Btw, I'm using an old Newworld G3, the one with ADB. The old one. :) > I'd say sysrq.txt should say: > > On PowerPC - Press 'ALT - Print Screen (or F13) - > On Newworld PPC - You press 'Keypad+ - Print Screen (or F13) - > > I'm still trying to figure out how to do it with the F13-less Keyboard.. Er, I thought you just said you did? What keycodes are you using? Most "Newworld" only have the F13-less keyboard. Which sort of raises the question of how 'Keypad +' worked instead of the "ALT" key (either option/alt or the scroll key, whichever changes VC). Which sounds more like a fluke then anything else. Which keyboard worked with 'Keypad +' ? The ADB one? After some quick playing with my oldworld machine, Just F13 - is sufficient. I'm not sure about PReP tho (so it's probably not worth saying you don't need "ALT"). -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.3-pre1 oops w/ rsync & ReiserFS
On Mon, 19 Mar 2001, David Raufeisen wrote: > Getting oops every time I run rsync today.. happens after it receives file list and >is starting to stat all the files.. filesystem is reiser. > > Linux prototype 2.4.3-pre1 #2 Thu Mar 15 00:24:43 PST 2001 i686 unknown > > 15:25:28 up 1 day, 20:05, 4 users, load average: 0.00, 0.03, 0.00 > > Linux prototype 2.4.3-pre1 #2 Thu Mar 15 00:24:43 PST 2001 i686 unknown David, Can you please use "memtest86" to check if your RAM does not have problems? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
KMALLOC_MAXSIZE undeclared in drivers/media/video/buz.c
2.4.3-pre4. i also see a reference to KMALLOC_MAXSIZE in drivers/net/hamradio/6pack.c this kernel won't compile, is KMALLOC_MAXSIZE set somewhere? i can't find it. is it deprecated? gcc -D__KERNEL__ -I/usr/src/RedmondLinux/BUILD/linux-2.4.3/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i586 -mcpu=i686 -DMODULE -DMODVERSIONS -include /usr/src/RedmondLinux/BUILD/linux-2.4.3/linux/include/linux/modversions.h -c -o buz.o buz.c buz.c: In function `v4l_fbuffer_alloc': buz.c:188: `KMALLOC_MAXSIZE' undeclared (first use in this function) buz.c:188: (Each undeclared identifier is reported only once buz.c:188: for each function it appears in.) buz.c: In function `jpg_fbuffer_alloc': buz.c:262: `KMALLOC_MAXSIZE' undeclared (first use in this function) buz.c:256: warning: `alloc_contig' might be used uninitialized in this function buz.c: In function `jpg_fbuffer_free': buz.c:322: `KMALLOC_MAXSIZE' undeclared (first use in this function) buz.c:316: warning: `alloc_contig' might be used uninitialized in this function buz.c: In function `zoran_ioctl': buz.c:2837: `KMALLOC_MAXSIZE' undeclared (first use in this function) make[3]: *** [buz.o] Error 1 make[3]: Leaving directory `/usr/src/RedmondLinux/BUILD/linux-2.4.3/linux/drivers/media/video' make[2]: *** [_modsubdir_video] Error 2 make[2]: Leaving directory `/usr/src/RedmondLinux/BUILD/linux-2.4.3/linux/drivers/media' make[1]: *** [_modsubdir_media] Error 2 make[1]: Leaving directory `/usr/src/RedmondLinux/BUILD/linux-2.4.3/linux/drivers' make: *** [_mod_drivers] Error 2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gettimeofday question
Eli Carter writes: > And you described (in much better detail) the same problem I was talking > about in the first email I sent today. Ok, at least we've got the same picture that we're working from now. > Yes, but it digs another to get the dirt to fill the first one. :/ for > instance: > > > > > read_lock_xtime_and_ints(); > > jiffies_1 = jiffies; > > counter_1 = counter; > > read_unlock_xtime_and_ints(); > > Time passes due to an interrupt handler but not a full jiffy, so > jiffies hasn't changed. > Also, what if this function is called with interrupts disabled? (Is > that legal?) If so, we've broken the locking expected by the caller. The calling function does indeed do the read_lock_xtime_and_ints() bit for us. However, we can always do a read_unlock(); sti(); read_lock_irq(); in do_gettimeofday(). Whether we want to or not is another matter, especially as its not nice for a called function to explicitly enable interrupts. As for timer interrupts taking more than 10ms, yes, that is another problem. ;( > Comments? This problem has a non-trivial solution, and I think whoever originally wrote the x86 do_gettimeofday code decided that it wasn't worth finding a solution to it. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: on /etc/mtab vs. /proc/mounts
On Mon, Mar 19, 2001 at 03:05:55PM -0800, Torrey Hoffman wrote: > In fact, the "mount" man page on my Mandrake 7.2 system says: > > "It is possible to replace /etc/mtab by a symbolic link to > /proc/mounts..." and then goes on to describe some of the issues and > problems with doing so - loopback, and paths with spaces seem to > be the significant ones. The spaces part was fixed in patch-2.4.0-test7. Today there is a different flaw again: After "mount --bind somedir mountpoint" there is no indication of somedir in /proc/mounts. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3rd version of R/W mmap_sem patch available
On Tue, 20 Mar 2001, Manfred Spraul wrote:
>
> Rik, did you check that {pte,pmd}_alloc are thread safe? At least in
> 2.4.2 they aren't (include/asm-i386/pgalloc.h), and your patch doesn't
> touch pgalloc.
Excellent point. We used to do all the looping and re-trying, but it got
ripped out a long time ago (and in any case, it historically didn't do
SMP, so the old code doesn't really work).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: atyfb,matrox hardlocks, multihead, USB broken, 2.4.2-ac8
Sorry, forgot to CC linux kernel... Elmer Joandi wrote: > > 2.4.2-ac8, with 4 graphics cards, Dual Celeron > now with 2.4.2-ac8 it is even more clear > any attempt to insert module ends with straight lockup > video mode swithc occurs and then ping to the box stops > immediately. > more, starting X locks kernel the same way. Try 'video=scrollback:0'. Scrollback code does not handle heads with different width correctly. Petr Vandrovec - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.3-pre1 oops w/ rsync & ReiserFS
Getting oops every time I run rsync today.. happens after it receives file list and is starting to stat all the files.. filesystem is reiser. Linux prototype 2.4.3-pre1 #2 Thu Mar 15 00:24:43 PST 2001 i686 unknown 15:25:28 up 1 day, 20:05, 4 users, load average: 0.00, 0.03, 0.00 Linux prototype 2.4.3-pre1 #2 Thu Mar 15 00:24:43 PST 2001 i686 unknown Gnu C 2.95.3 Gnu make 3.79.1 binutils 2.11.90.0.1 util-linux 2.11a modutils 2.4.2 e2fsprogs 1.19 reiserfsprogs 3.x.0b Linux C Library2.2.2 Dynamic linker (ldd) 2.2.2 Procps 2.0.7 Net-tools 1.59 Kbdcommand Sh-utils 2.0.11 Modules Loaded NVdriver prototype:~# ksymoops oops.txt ksymoops 2.3.7 on i686 2.4.3-pre1. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.3-pre1/ (default) -m /System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Unable to handle kernel paging request at virtual address 4280d8c4 c01410c0 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00210207 eax: c7fdc5e0 ebx: 4280d8ac ecx: 000e edx: 21cd5a87 esi: edi: c71424c0 ebp: 4280d8c4 esp: c37b1f04 ds: 0018 es: 0018 ss: 0018 Process rsync (pid: 16269, stackpage=c37b1000) Stack: c37b1f68 c71424c0 c37b1fa4 c7fdc5e0 c5919022 21cd5a87 000a c01392d0 c71424c0 c37b1f68 c37b1f68 c0139a92 c71424c0 c37b1f68 c5919000 c37b1fa4 c5919000 c01390da 0008 Call Trace: [] [] [] [] [] [] [] Code: 8b 6d 00 8b 54 24 18 39 53 48 75 7c 8b 44 24 24 39 43 0c 75 >>EIP; c01410c0<= Trace; c01392d0 Trace; c0139a92 Trace; c01390da Trace; c013a0dc <__user_walk+3c/60> Trace; c0137116 Trace; c012f453 Trace; c0108e8b Code; c01410c0 <_EIP>: Code; c01410c0<= 0: 8b 6d 00 mov0x0(%ebp),%ebp <= Code; c01410c3 3: 8b 54 24 18 mov0x18(%esp,1),%edx Code; c01410c7 7: 39 53 48 cmp%edx,0x48(%ebx) Code; c01410ca a: 75 7c jne88 <_EIP+0x88> c0141148 Code; c01410cc c: 8b 44 24 24 mov0x24(%esp,1),%eax Code; c01410d0 10: 39 43 0c cmp%eax,0xc(%ebx) Code; c01410d3 13: 75 00 jne15 <_EIP+0x15> c01410d5 1 warning issued. Results may not be reliable. -- David Raufeisen <[EMAIL PROTECTED]> Cell: (604) 818-3596 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3rd version of R/W mmap_sem patch available
On Mon, 19 Mar 2001, Linus Torvalds wrote: > > Excellent point. We used to do all the looping and re-trying, but it got > ripped out a long time ago (and in any case, it historically didn't do > SMP, so the old code doesn't really work). Actually, funnily enough, I see that the old thread-safe stuff is still there in get_pte_kernel_slow(). The only thing that breaks it is that we don't hold any locks, so it's only UP-safe, not SMP-safe. However, it definitely looks like we should just un-inline that thing completely, and make a lot of it architecture-independent anyway. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.2.18.02122001.patch
On Mon, Mar 19, 2001 at 09:09:21AM -0800, Andre Hedrick wrote: > > Write-caching flushing upon closing/unmounting each partition. Would it be possible to have such info included on the webpage and/or on the release emails? I often wonder what, if any, goodness might come from these patches but it's a wee bit hard to tell as it stands. -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. speaking of mental giants.. me, a giant, bullshit And i'm not mental - An IRC session, 20/12/2000 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3rd version of R/W mmap_sem patch available
>
> Besides, the fair semaphores would potentially slow things down, while
> this potentially speeds things up. So.. It looks obvious enough.
>
Rik, did you check that {pte,pmd}_alloc are thread safe? At least in
2.4.2 they aren't (include/asm-i386/pgalloc.h), and your patch doesn't
touch pgalloc.
{pte,pmd}_alloc are called from handle_mm_fault, and that function is
now running with down_read().
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] reiserfs tail bugs
Hello everyone,
This patch should close out the last known tail bug in my
queue. If you've still got small reiserfs files with the wrong
data in them, please start shouting.
The patch isn't very big, but changes some sensitive areas,
so I'm looking for more success reports on non-critical data
before inclusion anywhere else.
Short version: mozilla's elf-dynstr-gc could segfault if stripping
a small lib with tails turned on. You hit the bug when you
pack the tail, mmap & modify tail bytes, and truncate to some size
still inside the tail. Patch is below.
Long version:
1) _get_block_create_0 should not read the tail off disk when
the buffer is already up to date. The tail code maps tail
buffers in the page cache to block 0. In some cases,
_get_block_create_0 gets called on an unmapped, up to date page
buffer, with more recent data than the stuff in buffer cache.
2) Due to tail padding, direct items might have more bytes than
the file actually holds. In odd corruption cases, there might
be more direct bytes than there are bytes in the file. When the
truncate code reads the tail in, i_size can be smaller than the
direct item.
In other words, _get_block_create_0 might not want to read the
entire direct item off disk. New code added to make sure we don't
copy bytes past the end of the file into the page.
3) reiserfs_vfs_truncate file would zero the truncated bytes for
partial blocks in the page only when truncating from an indirect item.
It needs to zero the page for direct items too (to make sure the padded
bytes are zero).
4) flush_dcache_page added to _get_block_create_0.
5) buffers in the page cache are now marked up to date by
reiserfs_write_full_page as it maps/flushes them.
Patch against 2.4.3-pre3 (should be fine on pre4 too).
-chris
--- linux.1/fs/reiserfs/inode.c Sat Mar 17 14:13:34 2001
+++ linux/fs/reiserfs/inode.c Mon Mar 19 01:29:08 2001
@@ -304,6 +304,7 @@
char * p = NULL;
int chars;
int ret ;
+int done = 0 ;
unsigned long offset ;
// prepare the key to look for the 'block'-th block of file
@@ -355,6 +356,14 @@
return -ENOENT;
}
+/* if we've got a direct item, and the buffer was uptodate,
+** we don't want to pull data off disk again. skip to the
+** end, where we map the buffer and return
+*/
+if (buffer_uptodate(bh_result)) {
+goto finished ;
+}
+
// read file tail into part of page
offset = (cpu_key_k_offset(&key) - 1) & (PAGE_CACHE_SIZE - 1) ;
fs_gen = get_generation(inode->i_sb) ;
@@ -375,8 +384,24 @@
if (!is_direct_le_ih (ih)) {
BUG ();
}
- chars = le16_to_cpu (ih->ih_item_len) - path.pos_in_item;
+ /* make sure we don't read more bytes than actually exist in
+ ** the file. This can happen in odd cases where i_size isn't
+ ** correct, and when direct item padding results in a few
+ ** extra bytes at the end of the direct item
+ */
+if ((le_ih_k_offset(ih) + path.pos_in_item) > inode->i_size)
+ break ;
+ if ((le_ih_k_offset(ih) - 1 + ih_item_len(ih)) > inode->i_size) {
+ chars = inode->i_size - (le_ih_k_offset(ih) - 1) - path.pos_in_item;
+ done = 1 ;
+ } else {
+ chars = le16_to_cpu (ih->ih_item_len) - path.pos_in_item;
+ }
memcpy (p, B_I_PITEM (bh, ih) + path.pos_in_item, chars);
+
+ if (done)
+ break ;
+
p += chars;
if (PATH_LAST_POSITION (&path) != (B_NR_ITEMS (bh) - 1))
@@ -395,16 +420,14 @@
ih = get_ih (&path);
} while (1);
+finished:
pathrelse (&path);
-
-// FIXME: b_blocknr == 0 here. but b_data contains correct data
-// from tail. ll_rw_block will skip uptodate buffers
bh_result->b_blocknr = 0 ;
bh_result->b_dev = inode->i_dev;
mark_buffer_uptodate (bh_result, 1);
bh_result->b_state |= (1UL << BH_Mapped);
+flush_dcache_page(bh_result->b_page) ;
kunmap(bh_result->b_page) ;
-
return 0;
}
@@ -1567,8 +1590,9 @@
/* so, if page != NULL, we have a buffer head for the offset at
** the end of the file. if the bh is mapped, and bh->b_blocknr != 0,
** then we have an unformatted node. Otherwise, we have a direct item,
-** and no zeroing is required. We zero after the truncate, because the
-** truncate might pack the item anyway (it will unmap bh if it packs).
+** and no zeroing is required on disk. We zero after the truncate,
+** because the truncate might pack the item anyway
+** (it will unmap bh if it packs).
*/
prevent_flush_page_lock(page, p_s_inode) ;
journal_begin(&th, p_s_inode->i_sb, JOURNAL_PER_BALANCE_CNT * 2 ) ;
@@ -1578,7 +1602,7 @@
journal_end(&th, p_s_inode->i_sb, JOURNAL_PER_BALANCE_CNT * 2 ) ;
allow_flush_page_lock(page, p_s_inode) ;
-if (page && buffer_mapped(bh) && bh->b_blocknr != 0) {
+if (page) {
length = offse
Re: sysrq.txt
On Mon, Mar 19, 2001 at 11:56:19PM +0100, J. Michael Kolbe wrote: > On Mon, Mar 19, 2001 at 01:46:53PM -0700, Tom Rini wrote: > > On Mon, Mar 19, 2001 at 08:37:00PM +0100, J. Michael Kolbe wrote: > > > On Mon, Mar 19, 2001 at 09:15:59AM -0700, Tom Rini wrote: > > > > Speaking of reversed, there's a slightly "nicer" one in 2.2.18+: > > > > On PowerPC - You press 'ALT-Print Screen-'. > > > > > > > > (And yes, all the apple keyboards I've seen w/ F13 have Print Screen > > > > right below it). Tho I'm also rather sure this didn't get into > > > > Linus' tree until after the 2.3 split.. > > > > > > > Well, my Apple Keyboard doesn't. It's F13. And it doesn't work with 'ALT'. > > > I suppose that's why it didn't get into the mainstream tree. > > > > But anyways. My objects were it's not just "macs". And not all keyboards > > have "F13" written on them as well as Print Screen. Which is why I think > > what 2.2 has is what 2.4 should have. Or if yours doesn't say Print Screen: > > > > On PowerPC - You press 'ALT-Print Screen (or F13)- > > > > As to weather or not it's the key which says "ALT" on it or not, it is the > > key which provides the ALT keycode in linux. Or it very well should be, for > > consistencys sake. > > > Keypad'+''s keycode is 69, while ALT's keycode is 58. Err, so? The sysrq code is triggered by "ALT" (which on PPC can be any number of things, depending on keyboard and other stuff) and the SYSRQ key. It's either 0x69 or 0x54, which is "F13" in either translated keycodes or ADB respectivly. > Besides, I have never seen an Apple Keyboard without an F13 Key. All of the USB keyboards, up until recently. > So, it's "Keypad'+'-F13 (or Print Screen)-". > Any objection? Well, where does that work? My PReP works fine w/ ALT-printscrn-key My old pmac is ALT-printscrn-key, and I don't have F13 on my other keyboard. So yes, I object because I'm not sure where your sugjestion works. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 should better cope with power failure
On Mon, Mar 19, 2001 at 11:35:55PM +0100, Otto Wyss wrote: > > you can avoid all of these problems. Or use a journaling filesystem ext3/xfs, etc. > > So in real live you would propose to put fences and nets everywhere to > prevent children from possibly falling in abyses? I think you've got it backwards: from my point of view, _you_ are proposing the nets, _he_ is proposing the knowledgable and trustworthy parent looking after the children. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Si le dan dos órdenes contradictorias, obedezca las dos. -- Segunda Ley de Brintnall. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 should better cope with power failure
> Actually, I think /etc/mtab is not needed at all. Originally, UNIX > used to put as much onto the disk (and not in "core") as possible. > so much state information related only to one boot-cycle was > taken out of kernel and stored on disk. /var/run/utmp, /etc/mtab, > , rmtab, and many others. all are invalidated by a reboot, and are yet > stored > in non-volatile storage. kernel memory is not swappable, so they manually > separated out the minimum needed in core. > > Linux currently has a lot of this info in core, and maintains the disk files > for backwards compatibility. in the case of /etc/mtab, I believe > /proc/mounts > has the same info. It appears to be in the same format as /etc/mtab, > so most of the groundwork has already been done. > i've considered trying just changing /etc/mtab to /proc/mounts in some > utilities, to remove the need for read-write root. This (and other cases) > would guarantee consistency (look at /etc/mtab after restart in single > user more - ugh) It has been suggested to ln -sf /proc/mounts /etc/mtab. Linus has said this, I believe. -b - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 should better cope with power failure
Richard B. Johnson wrote: > Unix and other such variants have what's called a Virtual File System > (VFS). Correct, but hardly relevant here, except possibly that this enables you to use a different, perhaps more resilient file system. > The idea behind this is to keep as much recently-used file stuff > in memory so that the system can be as fast as if you used a RAM disk > instead of real physical (slow) hard disks. Correct, but does not require VFS. Nice try, though. - Werner -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
on /etc/mtab vs. /proc/mounts (Was RE: Linux should better cope with power failure)
(Recipients trimmed, as this is a major change of topic...) [big cut] > Actually, I think /etc/mtab is not needed at all. This is already mostly correct, AFAIK. My embedded system uses "busybox" for mount and umount, /etc/mtab does not exist, and the root file system is readonly. But if I do "umount -a" it works. So the busybox umount is already reading /proc/mounts. The only oddity I see with using /proc/mounts is that it shows: /dev/root / ext2 rw 0 0 instead of /dev/hda1 / ext2 rw 0 0 but this doesn't seem to cause any problems... even though /dev/root does not exist (!) In fact, the "mount" man page on my Mandrake 7.2 system says: "It is possible to replace /etc/mtab by a symbolic link to /proc/mounts..." and then goes on to describe some of the issues and problems with doing so - loopback, and paths with spaces seem to be the significant ones. Hopefully those problems can and will be solved soon, and then we can get rid of /etc/mtab completely, and keep the root partition read only almost all the time. Torrey Hoffman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 should better cope with power failure
Guy, I wrote APCUPSD beginning back in 95/96 for this reason. American Power Conversion is now friendly to Linux. http://www.linux-ide.org/apcupsd.html Cheers, On Mon, 19 Mar 2001, Stephen Satchell wrote: > At 01:16 PM 3/19/01 -0800, Torrey Hoffman wrote: > >Yes. Some of this is your responsibility. You have several options: > >1. Get a UPS. That would not have helped your particular problem, > >but it's a good idea if you care about data integrity. > >2. Use a journaling file system. These are much more tolerant of > >abuse. Reiserfs seems to work for me on embedded systems I am > >building where the user can (and does) remove the power any time. > >3. Use RAID. Hard drives are very cheap and software raid is very > >easy to set up. > > Sorry, but you really should have read the ENTIRE thread before > commenting. This guy's original complaint was that his USB keyboard locks > up, and the only way to get it back is to do a very rude restart. In > combatting this problem, the guy was observing the "shortcomings" of the > file system. > > To be more to the point of the guy's problem, he should consider using > software specifically intended for UPS hardware to notify a system when the > power is going to go, and wire up an appropriate switch to signal his > system to enter shutdown when his keyboard goes south. By forcing an > orderly shutdown, he doesn't see the fsck-ing messages, he gets his USB > keyboard back, and all is well with the world. > > Of course, the other option is to use a regular keyboard instead of a USB > keyboard, but why point out the really easy solution? "Hey Doc, it hurts > when I do this." "Then don't do it." > > Satch > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > Andre Hedrick Linux ATA Development ASL Kernel Development - ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035Web: www.aslab.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: gettimeofday question
Russell King wrote:
>
> Eli Carter writes:
> > What are you seeing that I'm missing?
>
> Ok, after sitting down and thinking again about this problem, its not
> the 9.ms case, but the 10.1 case:
And you described (in much better detail) the same problem I was talking
about in the first email I sent today.
gettimeoffset does not handle cases >10ms.
> Like I say, this requires good timing to create, so may not be too much of
> a problem, but it does seem to be a problem that could occur.
You should be able to create this "maliciously" within the kernel (or
with bad driver code...) with something like:
Disable interrupts for 10ms, then call gettimeofday, reenable
interrupts, then call gettimeofday.
(I think.)
> I'm wondering if something like the following will plug this hole:
Yes, but it digs another to get the dirt to fill the first one. :/ for
instance:
>
> read_lock_xtime_and_ints();
> jiffies_1 = jiffies;
> counter_1 = counter;
> read_unlock_xtime_and_ints();
Time passes due to an interrupt handler but not a full jiffy, so
jiffies hasn't changed.
Also, what if this function is called with interrupts disabled? (Is
that legal?) If so, we've broken the locking expected by the caller.
> read_lock_xtime_and_ints();
And just for giggles, the counter rolls over here. (And with interrupts
disabled, jiffies isn't updated yet...)
> jiffies_2 = jiffies;
> counter_2 = counter;
> read_unlock_xtime_and_ints();
>
> if (jiffies_1 != jiffies_2) {
> /*
> * we rolled over while reading counter_1. Therefore
> * we can't trust it. Use *_2 instead. Note that we
> * would have received an interrupt between read_unlock
> * and read_lock.
> */
> jiffies_1 = jiffies_2;
> counter_1 = counter_1;
> } else {
> /*
> * we didn't roll over while reading counter_1
> * we can safely use counter_1 as is. Neither
> * did we receive a timer interrupt between the
> * read_unlock and read_lock.
> */
> }
>
> /* apply standard counter correction factor */
Which might be just less than 10ms inaccurate due to that interrupt
handler that ran after we read the times. So we are no more accurate
than before. :/
Unless you use counter_2, but then you have the original problem again.
> The only thing I haven't looked at is whether xtime would be updated.
That is updated in the timer bottom half; jiffies and lost_ticks are
updated in the timer interrupt. lost_ticks is then used by the bottom
half to update xtime. (That's why the gettimeofday portion references
lost_ticks.)
Comments?
Eli
---. Rule of Accuracy: When working toward
Eli Carter |the solution of a problem, it always
eli.carter(at)inet.com `-- helps if you know the answer.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3rd version of R/W mmap_sem patch available
> Now the code is beautiful and it might even be bugfree ;) I'm applying this to my tree - I'm not exactly comfortable with this during the 2.4.x timeframe, but at the same time I'm even less comfortable with the current alternative, which is to make the regular semaphores fairer (we tried it once, and the implementation had problems, I'm not going to try that again during 2.4.x). Besides, the fair semaphores would potentially slow things down, while this potentially speeds things up. So.. It looks obvious enough. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux should better cope with power failure
"Stephen Gutknecht (linux-kernel)" wrote: > > Otto, > [...] > Have you considered telnet into your box from a second machine? Even a 486 > system would do this fine... network cards are cheap. You could try to > recover the system or at least do a shutdown. > It was just a simple test machine where it didn't matter what was lost. Still that doesn't justify this behaviour. O. Wyss - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 should better cope with power failure
Jeremy Jackson wrote: > > Brian Gerst wrote: > > > "Richard B. Johnson" wrote: > > > > > > On Mon, 19 Mar 2001, Otto Wyss wrote: > > > > > > > Lately I had an USB failure, leaving me without any access to my system [..] > > > Unix and other such variants have what's called a Virtual File System > > > (VFS). The idea behind this is to keep as much recently-used file stuff > > > in memory so that the system can be as fast as if you used a RAM disk > > > instead of real physical (slow) hard disks. If you can't cope with this, > > > use DOS. > > > > At the very least the disk should be consistent with memory. If the > > dirty pages aren't written back to the disk (but not necessarily removed > > from memory) after a reasonable idle period, then there is room for > > improvement. > > They are. If you leave your machine one for a minute or so (probably less is ok, > but I don't know) the kernel will flush dirty buffers... fsck will complain, but the > file's There was at least 15min I waited without doing anything (how could I without any imput device). I was editing a file with vim and the usual bunch of demons where running mostly doing nothing. I don't know if all the complains from fsck where due to open files or dirty cache pages. I wouldn't complain if there was any heavy activity but there was allmost none. > *data* blocks will be on the disk. There are way more reasons that this is a silly > and annoying thread. You should read more about things like > asynchronous/synchronous filesystems, > lazy-write cacheing, etc, etc,. If you know how to write software and/or configure > your system, > you can avoid all of these problems. Or use a journaling filesystem ext3/xfs, etc. > But I tire of this... So in real live you would propose to put fences and nets everywhere to prevent children from possibly falling in abyses? O. Wyss - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 should better cope with power failure
At 01:16 PM 3/19/01 -0800, Torrey Hoffman wrote: >Yes. Some of this is your responsibility. You have several options: >1. Get a UPS. That would not have helped your particular problem, >but it's a good idea if you care about data integrity. >2. Use a journaling file system. These are much more tolerant of >abuse. Reiserfs seems to work for me on embedded systems I am >building where the user can (and does) remove the power any time. >3. Use RAID. Hard drives are very cheap and software raid is very >easy to set up. Sorry, but you really should have read the ENTIRE thread before commenting. This guy's original complaint was that his USB keyboard locks up, and the only way to get it back is to do a very rude restart. In combatting this problem, the guy was observing the "shortcomings" of the file system. To be more to the point of the guy's problem, he should consider using software specifically intended for UPS hardware to notify a system when the power is going to go, and wire up an appropriate switch to signal his system to enter shutdown when his keyboard goes south. By forcing an orderly shutdown, he doesn't see the fsck-ing messages, he gets his USB keyboard back, and all is well with the world. Of course, the other option is to use a regular keyboard instead of a USB keyboard, but why point out the really easy solution? "Hey Doc, it hurts when I do this." "Then don't do it." Satch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] question about functions that can fail
Dawson writes: > right now we are trying to derive which functions can "reasonably" fail > by examining all call sites and recording the number of times functions > are checked vs not checked. First of all, thanks for this interesting work you are doing. Pre-emptive bug squashing is great. Probably saved many man-years of grief for people who are having intermittent problems, or have uncommon hardware/configuration. > I've included the most egregious cases of check/not checked: > >parse_options : 14 : 1: It appears you are not making a distinction between static functions and global functions. The parse_options function is local to ext2, but since many filesystem writers look at ext2 for guidance, they often have functions with similar names. It looks like parse_options is one of the common ones. That said, I'm guessing the 1 time the return value isn't checked is a bug. It appears to be in fs/proc/inode.c, and the parse_options() there _does_ return 1 on error (unknown mount option), so we _should_ probably fail mounting /proc in that case. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 should better cope with power failure
"Richard B. Johnson" wrote: > On Mon, 19 Mar 2001, Brian Gerst wrote: > [SNIPPED...] > > > > > At the very least the disk should be consistent with memory. If the > > dirty pages aren't written back to the disk (but not necessarily removed > > from memory) after a reasonable idle period, then there is room for > > improvement. > > > > Hmmm. Now think about it a minute. You have a database operation > with a few hundred files open, most of which will be deleted after > a sort/merge completes. At the same time, you've got a few thousand > directories with their ATIME being updated. Also, you have thousands > of temporary files being created in /tmp during a compile that didn't > use "-pipe". > > If you periodically write everything to disk, you don't have many > CPU cycles available to do anything useful. > > It is up to the application to decide if anything is 'precious'. > If you've got some database running, it's got to be checkpointed > with some "commitable" file-system so it can be interrupted at any time. > > If you make your file-systems up of "slices", you can mount the > executable stuff read/only. Currently, only /var and /tmp need to > be writable for normal use, plus any user "slices", of course. > -- Yes I know you need to modify /etc/stuff occasionally (startup > and shutdown, plus an occasional password change). I proposed > a long time ago that /etc/mtab get moved to /var. so how does mount update /var/mtab when mounting var? he he. Actually, I think /etc/mtab is not needed at all. Originally, UNIX used to put as much onto the disk (and not in "core") as possible. so much state information related only to one boot-cycle was taken out of kernel and stored on disk. /var/run/utmp, /etc/mtab, , rmtab, and many others. all are invalidated by a reboot, and are yet stored in non-volatile storage. kernel memory is not swappable, so they manually separated out the minimum needed in core. Linux currently has a lot of this info in core, and maintains the disk files for backwards compatibility. in the case of /etc/mtab, I believe /proc/mounts has the same info. It appears to be in the same format as /etc/mtab, so most of the groundwork has already been done. i've considered trying just changing /etc/mtab to /proc/mounts in some utilities, to remove the need for read-write root. This (and other cases) would guarantee consistency (look at /etc/mtab after restart in single user more - ugh) I wonder if embedded folks would like to at least keep the old behaviour as a compile-time option; they're in almost the same boat as early (64k core memory) unix folks. My favorite compromise between journaling and performance is the compaq smart array controllers, with a battery-backed sram write cache; they can do (fast)lazy writes and still be perfectly reliable. plus they keep *everything* reliable, not just metadata. I find this a fascinating topic... the ultimate would be to use the nvram (it's mostly empty if using LinuxBIOS) to store a clean shutdown flag, and/or a system heartbeat timestamp (like syslogd's)... only this timestamp would let the hdd spin down (not hit every 20 minutes or so with a timestamp log entry) and not wear out a flash disk based system. Regards, Jeremy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: UDMA 100 / PIIX4 question
On Mon, 19 Mar 2001 12:17:38 -0800
Tim Moore <[EMAIL PROTECTED]> wrote:
> Jeremy Jackson wrote:
> >
> > Tim Moore wrote:
> > > 15MB/s for hdparm is about right.
> >
> > Yes, since hdparm -t measures *SUSTAINED* transfers... the actual
> "head rate" of data reads from
> > disk surface. Only if you read *only* data that is alread in
> harddrive's cache will you get a speed
> > close to the UDMA mode of the drive/controller. The cache is around
> 1Mbyte, so for a split-second
> > re-read of some data
>
> Apologies for the too brief answer. Sustained real world transfer rates
> for the PIIX4 under ideal
> setup conditions and a quiet bus are 14-18MB/s. Faster disk
> architecture and forcing ide driver
> parameters will not change this.
>
> Here's what you might expect from this disk family with an ATA-66
> capable chipset:
>
> [tim@abit tim]# hdparm -i /dev/hda; hdparm -tT /dev/hda
>
> /dev/hda:
> Timing buffer-cache reads: 128 MB in 0.81 seconds =158.02 MB/sec
> Timing buffered disk reads: 64 MB in 1.85 seconds = 34.59 MB/sec
>
> Larger sustained transfers are about 75% of the burst/cache influenced
> hdparm timings.
>
> [tim@abit tim]# time dd if=/dev/hda of=/dev/null bs=1k count=500k
> 512000+0 records in
> 512000+0 records out
> 0.340u 6.780s 0:19.68 36.1% 0+0k 0+0io 115pf+0w
> [tim@abit tim]# echo "512000/19.68" | bc -q
> 26016
>
Hi,
First, many thanks to you both for responding (and Jerry for his further post
mentioned below). Can I throw in the some actual figures just obtained on my system,
and ask if these are consistent with what you are saying ?
cat /proc/ide/piix :
Intel PIIX4 Ultra 100 Chipset.
--- Primary Channel Secondary Channel -
enabled enabled
--- drive0 - drive1 drive0 -- drive1 --
DMA enabled:yes no yes no
UDMA enabled: yes no yes no
UDMA enabled: 5X 2 X
UDMA
DMA
PI
hdparm -tT /dev/hda :
/dev/hda:
Timing buffer-cache reads: 128 MB in 1.04 seconds =123.08 MB/sec
Timing buffered disk reads: 64 MB in 4.24 seconds = 15.09 MB/sec
time dd if=/dev/hda of=/dev/null bs=1k count=500k :
512000+0 records in
512000+0 records out
real0m26.636s
user0m0.220s
sys 0m8.190s
(d) bonnie -s 1000
---Sequential Output (nosync)--- ---Sequential Input-- --Rnd Seek-
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --04k (03)-
MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
1*1000 10532 91.3 17757 11.3 6481 5.2 9604 71.1 20937 12.1 131.7 1.9
I had just written the above when the following post from Jeremy arrived :
"You should be able to get about 30 MB/s at the start of the disk (zone 0)
so if you were testing say /dev/hda1 which is at the start of the disk it should be
faster.
Try hdparm -i /dev/hda (or whatever) .. . note the reported MaxMultSect= value,
and put it in place of X in command:
hdparm -u 1 -d 1 -m X -c 1 /dev/hda
Cheers,
Jeremy
PS - please let me know if this fixed your problem, since I have a system
with the same motherboard."
There is a Win partition - so I do not think I am at the start of the drive.
hdparm -i /dev/hda gives :
/dev/hda:
Model=IBM-DTLA-307030, FwRev=TX4OA50C, SerialNo=YKDYKLN6151
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40
BuffType=3(DualPortCache), BuffSize=1916kB, MaxMultSect=16, MultSect=16
DblWordIO=no, OldPIO=2, DMA=yes, OldDMA=2
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=60036480
tDMA={min:120,rec:120}, DMA modes: mword0 mword1 mword2
IORDY=on/off, tPIO={min:240,w/IORDY:120}, PIO modes: mode3 mode4
UDMA modes: mode0 mode1 mode2 mode3 mode4 *mode5
Drive Supports : Reserved : ATA-2 ATA-3 ATA-4 ATA-5
I therefore tried hdparm -u 1 -d 1 -m 16 -c 1 -X69 /dev/hda :
/dev/hda:
setting 32-bit I/O support flag to 1
setting multcount to 16
setting unmaskirq to 1 (on)
setting using_dma to 1 (on)
setting xfermode to 69 (UltraDMA mode5)
multcount= 16 (on)
I/O support = 1 (32-bit)
unmaskirq= 1 (on)
using_dma= 1 (on)
Then hdparm -tT /dev/hda
/dev/hda:
Timing buffer-cache reads: 128 MB in 1.04 seconds =123.08 MB/sec
Timing buffered disk reads: 64 MB in 4.08 seconds = 15.69 MB/sec
These are, I fear, the figures I usually see.
Bed-time for Brits.
Regards,
Geoff
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.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
RE: Linux should better cope with power failure
Otto, If you are doing development work (or playing with new kernels) and things like USB failures lock you from keyboard and mouse... Have you considered telnet into your box from a second machine? Even a 486 system would do this fine... network cards are cheap. You could try to recover the system or at least do a shutdown. Maybe there are reason you have ruled this out; just making sure you haven't overlooked a possible prevention solution. Stephen Gutknecht Renton, Washington http://www.RoundSparrow.com/ -Original Message- From: Otto Wyss [mailto:[EMAIL PROTECTED]] Sent: Monday, March 19, 2001 11:47 AM To: [EMAIL PROTECTED] Subject: Linux should better cope with power failure Lately I had an USB failure, leaving me without any access to my system since I only use an USB-keyboard/-mouse. All I could do in that situation was switching power off and on after a few minutes of inactivity. From the impression I got during the following startup, I assume Linux (2.4.2, EXT2-filesystem) is not very suited to any power failiure or manually switching it off. Not even if there wasn't any activity going on. [snip] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 should better cope with power failure
"Richard B. Johnson" wrote: > > On Mon, 19 Mar 2001, Brian Gerst wrote: > [SNIPPED...] > > > > > At the very least the disk should be consistent with memory. If the > > dirty pages aren't written back to the disk (but not necessarily removed > > from memory) after a reasonable idle period, then there is room for > > improvement. > > > > Hmmm. Now think about it a minute. You have a database operation > with a few hundred files open, most of which will be deleted after > a sort/merge completes. At the same time, you've got a few thousand > directories with their ATIME being updated. Also, you have thousands > of temporary files being created in /tmp during a compile that didn't > use "-pipe". > > If you periodically write everything to disk, you don't have many > CPU cycles available to do anything useful. Note the key words "reasonable idle period". It was stated elsewhere that this is the case already so it is a moot point. -- Brian Gerst - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: UDMA 100 / PIIX4 question
Mark Hahn wrote: > > > > > I have an IBM DTLA 307030 (ATA 100 / UDMA 5) on an 815e board (Asus CUSL2), >which has a PIIX4 controller. > > > > ... > > > > My problem is that (according to hdparm -t), I never get a better transfer >rate than approximately 15.8 Mb/sec > > > > > > 15MB/s for hdparm is about right. > > it's definitely not right: this disk sustains around 35 MB/s. The 815e does not use a PIIX4 chipset. My references were to PIIX4 chipsets. > nonsequitur: the controller and disk are both quite capable of > sustaining 20-35 MB/s (depending on zone.) here's hdparm output > for a disk of the same rpm and density as the DTLA's: > > Timing buffer-cache reads: 128 MB in 1.07 seconds =119.63 MB/sec > Timing buffered disk reads: 64 MB in 2.02 seconds = 31.68 MB/sec > > (maxtor dm+45, hpt366 controller) > regards, mark hahn. Again, this is not a PIIX4 chipset. rgds, tim. -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.3-pre4: Unable to handle kernel NULL pointer dereference at virtual address 000000fb
I have included the ksymoops debug and dmesg (both small).. Any ideas? Shawn. ksymoops 2.3.7 on i586 2.4.3-pre4. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.3-pre4/ (default) -m /boot/System.map (specified) Intel Pentium with F0 0F bug - workaround enabled. Unable to handle kernel NULL pointer dereference at virtual address 00fb c2016531 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010082 eax: ebx: c0709dc8 ecx: c10e3a60 edx: c1258800 esi: edi: 0082 ebp: c1258878 esp: c0709f54 ds: 0018 es: 0018 ss: 0018 Process scsi_eh_0 (pid: 297, stackpage=c0709000) Stack: 0282 c1258800 c1274a00 c20165cf c1258800 c1258878 0282 c1274a00 c019dddf c1274a00 2003 c019e427 c1274a00 c0708000 c0709fdc c0709fdc c1258800 c0709fe8 c0709fe8 c10e3a60 c019e8fb Call Trace: [] [] [] [] [] Code: f6 80 fb 00 00 00 10 75 70 8b 4d 00 31 d2 eb 0a 89 ca 8b 82 >>EIP; c2016531 <[aha152x]free_hard_reset_SCs+21/ac> <= Trace; c20165cf <[aha152x]aha152x_bus_reset+13/a0> Trace; c019dddf Trace; c019e427 Trace; c019e8fb Trace; c010742c Code; c2016531 <[aha152x]free_hard_reset_SCs+21/ac> <_EIP>: Code; c2016531 <[aha152x]free_hard_reset_SCs+21/ac> <= 0: f6 80 fb 00 00 00 10 testb $0x10,0xfb(%eax) <= Code; c2016538 <[aha152x]free_hard_reset_SCs+28/ac> 7: 75 70 jne79 <_EIP+0x79> c20165aa <[aha152x]free_hard_reset_SCs+9a/ac> Code; c201653a <[aha152x]free_hard_reset_SCs+2a/ac> 9: 8b 4d 00 mov0x0(%ebp),%ecx Code; c201653d <[aha152x]free_hard_reset_SCs+2d/ac> c: 31 d2 xor%edx,%edx Code; c201653f <[aha152x]free_hard_reset_SCs+2f/ac> e: eb 0a jmp1a <_EIP+0x1a> c201654b <[aha152x]free_hard_reset_SCs+3b/ac> Code; c2016541 <[aha152x]free_hard_reset_SCs+31/ac> 10: 89 ca mov%ecx,%edx Code; c2016543 <[aha152x]free_hard_reset_SCs+33/ac> 12: 8b 82 00 00 00 00 mov0x0(%edx),%eax Linux version 2.4.3-pre4 (root@stucko) (gcc version 2.95.3 20010219 (prerelease)) #1 Sun Mar 18 01:29:02 EST 2001 BIOS-provided physical RAM map: BIOS-88: 0009f000 @ (usable) BIOS-88: 0170 @ 0010 (usable) On node 0 totalpages: 6144 zone(0): 4096 pages. zone(1): 2048 pages. zone(2): 0 pages. Kernel command line: auto BOOT_IMAGE=Linux ro root=302 Initializing CPU#0 Detected 83.524 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 166.29 BogoMIPS Memory: 22124k/24576k available (996k kernel code, 2064k reserved, 382k data, 60k init, 0k highmem) Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 2048 (order: 2, 16384 bytes) CPU: Before vendor init, caps: 013f , vendor = 0 Intel Pentium with F0 0F bug - workaround enabled. CPU: After vendor init, caps: 013f CPU: After generic, caps: 013f CPU: Common caps: 013f CPU: Intel OverDrive PODP5V83 stepping 02 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX isapnp: Scanning for Pnp cards... isapnp: Card 'Adaptec AVA-1505AI' isapnp: Card '3Com 3C509B EtherLink III' isapnp: 2 Plug & Play cards detected total Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 parport0: PC-style at 0x378 [PCSPP(,...)] pty: 256 Unix98 ptys configured block: queued sectors max/low 14605kB/4868kB, 64 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx keyboard: Timeout - AT keyboard not present? keyboard: Timeout - AT keyboard not present? hda: ST3491A D, ATA DISK drive hdb: QUANTUM PD210A, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: 836070 sectors (428 MB) w/120KiB Cache, CHS=899/15/62 hdb: 408564 sectors (209 MB) w/32KiB Cache, CHS=873/13/36 Partition check: hda: hda1 hda2 hdb: hdb1 hdb2 paride: epat registered as protocol 0 pd: pd version 1.05, major 45, cluster 64, nice 0 pda: Sharing parport0 at 0x378 pda: epat 1.01, Shuttle EPAT chip c6 at 0x378, mode 1 (5/3), delay 1 pda: AVATAR AR2250, master, 489472 blocks [239M], (956/16/32), removable media pda: pda1 Floppy drive(s): fd0 is 1.44M FDC 0 is an 8272A eth0: 3c509 at 0x220, 10baseT port, address 00 a0 24 46 41 c0, IRQ 5. 3c509.c:1.16 (2.2) 2/3/98 [EMAIL PROTECTED] loop: loaded (max 8 devices) Serial driver version 5.05 (2000-12-13) with ISAPNP enabled ttyS00 at 0x03f8 (irq = 4) is a 16450 ttyS01 at 0x02f8 (irq = 3) is a 16450 SCSI subsystem driver
atyfb,matrox hardlocks, multihead, USB broken, 2.4.2-ac8
2.4.2-ac8, with 4 graphics cards, Dual Celeron now with 2.4.2-ac8 it is even more clear any attempt to insert module ends with straight lockup video mode swithc occurs and then ping to the box stops immediately. more, starting X locks kernel the same way. meantime I changed from BIOS the AGP to be primary video. this was probably what made the most of difference as AGP is with largest PCI ID. USB is also nonworking. 2.4.0 was most part OK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Non-root sshd and capabilities
[cc: security-audit, because it's interesting :-)] On Sun, 18 Mar 2001, Topi Miettinen wrote: > (Please cc: me, I'm not subscribed.) > > Using the magical prctl() call it's possible to run daemons as non-root > while still possessing some capabilities. For full support, patched kernel > with ext2 capabilities is required, but if the daemon doesn't exec() > anything (for example, by emulating exec() with mmap()), stock 2.4 is > enough. Kernel 2.2.18 (I think) also added this prctl(). > This works well for programs like pppd, hwclock and XFree86. There is a > problem if the daemon uses setuid() and setgid() to change identity, like > sshd or cron. In function cap_emulate_setxuid() (in kernel/sys.c) the > capabilities are cleared when IDs are switched. However, the check misses > the case where old_*uid are already nonzero. This patch attempts to fix > the problem. [...] > Any suggestions? No comments on the patch/bug you've highlighted, but I've got some comments on the general approach. Firstly, changing sshd so it runs with minimal privilege, is an excellent project. You only need to look at the recent deattack.c vulnerability to see why. I was going to tackle this once I finished vsftpd (also makes use of capabilities and the prctl()). However, I don't think running any daemon with CAP_SETUID can be considered running with "minimal privilege". With CAP_SETUID, you can change your uid to the owner of any number of critical system files, and gain full access, as if you hadn't bothered using capabilities at all. Even inside a chroot() jail, you have to be careful with CAP_SETUID. Think "ptrace(), sysctl()". Of course, _something_ needs to have CAP_SETUID, otherwise you cannot switch to the authenticated userid at all. The solution is to have a minimal privileged helper process, which takes authentication details from the main sshd process over a pipe or socket. The helper process carefully validates the authentication details, and if they are correct, switches to the authenticated user, drops privileges, and runs some action on behalf of sshd. The above is a bit of hassle, but extremely powerful and secure. If you also throw in a bit of chroot(), you can make future sshd holes very low severity indeed. For bonus points, make sure that sensitive information such as the private host key, is only accesible to the privileged helper. Trickier (maybe not feasible), but useful. Finally, a comprised sshd session should not be able to compromise other sshd sessions. This can be accomplished by ensuring the sshd session processes all have "dumpable == 0" in the kernel, e.g. by starting sshd as root and doing setuid() to some other userid without any exec() Cheers Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[CHECKER] question about functions that can fail
Hi All, right now we are trying to derive which functions can "reasonably" fail by examining all call sites and recording the number of times functions are checked vs not checked. Checking includes comparisions <, >, != 0 directly: /* these are all checked uses */ if(foo()) if(foo() < 0) if(foo() == 0) ... ... ... As well as through variables: res = foo();res = foo(); /* result checked *//* result killed, so not checked */ if(res < 0) res = 0; ... The analysis is somewhat noisy since we do not recognize all checks correctly, and sometimes count non-checks as checks. However, with that said, the initial results look like there are: - 7803 integer functions that return values - 7149 consistently always check their result or never check their result. - which leaves 654 that have some inconsitencies, where results are checked sometimes but not others. Both ends of the inconsistent population are interesting: - we'd expect that a missing check on an almost-always checked function is likely to be a bug - we'd expect that a check on a function that is almost never checked is possibly the result of a misunderstood interface. (e.g., foo() can't fail, but the programmer mistakenly checks anyway). While cases such as request_irq seem like no brainers, I'm not familiar enough with the kernel to make the judgement call on many of the others. I've included the most egregious cases of check/not checked --- if anyone has time to glance through them and say which they think are good to check/warn about misunderstood interfaces, we'd appreciate it. We also have these results for routines that return pointers. I can send these too, if there is interest. Dawson --- Function : Times Checked : Not Checked request_irq: 246 : 13: pci_enable_device: 118 : 5: usb_submit_urb: 99 : 6: filldir: 89 : 6: serial_paranoia_check: 57 : 1: skb_queue_len: 56 : 2: denormal_operand: 45 : 4: get_tuple: 44 : 5: i2o_query_scalar: 38 : 3: permission: 32 : 1: path_walk: 32 : 1: devfs_register_chrdev: 31 : 1: path_init: 28 : 1: tty_check_change: 21 : 1: ntfs_read_attr: 20 : 1: fh_verify: 19 : 1: WaitReady: 19 : 1: get_zeroed_page: 20 : 2: fb_alloc_cmap: 20 : 2: sock_queue_rcv_skb: 16 : 1: inode_change_ok: 15 : 1: idetape_queue_pc_tail: 15 : 1: parse_options: 14 : 1: ethdev_init: 13 : 1: ftape_report_operation: 11 : 1: fdc_issue_command: 11 : 1: autofs4_oz_mode: 11 : 1: hfs_bfind: 10 : 1: autofs_oz_mode: 9 : 1: Sense: 9 : 1: --- ide_do_drive_cmd: 1 : 10: UxCardPortIoInW: 1 : 10: ((*((*dev).ops)).phy_get): 1 : 10: clear_epp_timeout: 2 : 11: send_sig_info: 1 : 10: unregister_blkdev: 1 : 11: cramfs_inflate_blocks: 1 : 12
Re: Linux should better cope with power failure
On Mon, 19 Mar 2001, Brian Gerst wrote: [SNIPPED...] > > At the very least the disk should be consistent with memory. If the > dirty pages aren't written back to the disk (but not necessarily removed > from memory) after a reasonable idle period, then there is room for > improvement. > Hmmm. Now think about it a minute. You have a database operation with a few hundred files open, most of which will be deleted after a sort/merge completes. At the same time, you've got a few thousand directories with their ATIME being updated. Also, you have thousands of temporary files being created in /tmp during a compile that didn't use "-pipe". If you periodically write everything to disk, you don't have many CPU cycles available to do anything useful. It is up to the application to decide if anything is 'precious'. If you've got some database running, it's got to be checkpointed with some "commitable" file-system so it can be interrupted at any time. If you make your file-systems up of "slices", you can mount the executable stuff read/only. Currently, only /var and /tmp need to be writable for normal use, plus any user "slices", of course. -- Yes I know you need to modify /etc/stuff occasionally (startup and shutdown, plus an occasional password change). I proposed a long time ago that /etc/mtab get moved to /var. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gettimeofday question
Eli Carter writes:
> What are you seeing that I'm missing?
Ok, after sitting down and thinking again about this problem, its not
the 9.ms case, but the 10.1 case:
First time:
- interrupts disabled
- read jiffies
- read counter
- jiffies_p != jiffies_t
- set jiffies_p = jiffies_t
- set counter_p = counter
- correction of (latch - counter) applied -> almost a full 10ms
- interrupts enabled
- counter rolls over
- jiffies updated
- counter is at, or near maximum
- time returned we'll call "0".
10.001ms later:
- interrupts disabled
- read jiffies
- counter rolls over
- read counter
- jiffies_p != jiffies_t
- set jiffies_p = jiffies_t
- set counter_p = counter
- correction of (latch - counter) applied -> almost nothing
- interrupts enabled
- jiffies updated
- time returned - "0" + almost nothing
Next read immediately after:
- interrupts disabled
- read jiffies
- read counter
- jiffies_p != jiffies_t
- set jiffies_p = jiffies_t
- set counter_p = counter
- correction of (latch - counter) applied -> slightly more than
almost nothing
- interrupts enabled
- time returned - "10ms" + slightly more than almost nothing
Like I say, this requires good timing to create, so may not be too much of
a problem, but it does seem to be a problem that could occur.
I'm wondering if something like the following will plug this hole:
read_lock_xtime_and_ints();
jiffies_1 = jiffies;
counter_1 = counter;
read_unlock_xtime_and_ints();
read_lock_xtime_and_ints();
jiffies_2 = jiffies;
counter_2 = counter;
read_unlock_xtime_and_ints();
if (jiffies_1 != jiffies_2) {
/*
* we rolled over while reading counter_1. Therefore
* we can't trust it. Use *_2 instead. Note that we
* would have received an interrupt between read_unlock
* and read_lock.
*/
jiffies_1 = jiffies_2;
counter_1 = counter_1;
} else {
/*
* we didn't roll over while reading counter_1
* we can safely use counter_1 as is. Neither
* did we receive a timer interrupt between the
* read_unlock and read_lock.
*/
}
/* apply standard counter correction factor */
The only thing I haven't looked at is whether xtime would be updated.
--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ata100 controller question
I've searched the kernel Documentation directory (linux 2.4.x) and I can't find anything about which IDE - ata100 pci cards are supported. I also looked in the Doc directory for my 2.2.12 kernel with no luck either. I've purchased the only one I could find at the comp-usa near me (Maxtor) and their web site doesn't even tell me what chipset it uses. I wanted to verify that it will work before I open it up, or they won't take it back for a refund. Next I searched the linux-kernel archives for maxtor, and saw some things about disks, but nothing about the controller, so I guess it has never come up??? Where am I supposed to find this kind of information? thanks, -chuck -- ACCEL Services, Inc.| Specialists in Gravity, Magnetics | 1(713)993-0671 ph. 1980 Post Oak Blvd. | and Integrated Interpretation | 1(713)960-1157 fax Suite 2050 | | Houston, TX, 77056 | Chuck Campbell | [EMAIL PROTECTED] | President & Senior Geoscientist | "Integration means more than having all the maps at the same scale!" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 should better cope with power failure
Otto Wyss wrote: > situation was switching power off and on after a few minutes of > inactivity. From the impression I got during the following startup, I You aren't giving a lot of detail here. I assume your startup scripts run fsck, and you saw a lot of errors. Were any of them uncorrectable? > assume Linux (2.4.2, EXT2-filesystem) is not very suited to any power > failiure or manually switching it off. Not even if there wasn't any > activity going on. That is correct. Pulling the plug on non-journaled filesystems is a bad idea. > Shouldn't a good system allways try to be on the save side? Yes. Some of this is your responsibility. You have several options: 1. Get a UPS. That would not have helped your particular problem, but it's a good idea if you care about data integrity. 2. Use a journaling file system. These are much more tolerant of abuse. Reiserfs seems to work for me on embedded systems I am building where the user can (and does) remove the power any time. 3. Use RAID. Hard drives are very cheap and software raid is very easy to set up. > There is currently much work done in > getting high performance during high activity but it seems there is no > work done at all in getting a save system during low/no activity. Actually, a lot of work _is_ being done on journaling file systems which help solve this problem. Current journaling file systems are metadata only, but Tux2 (if I understand it) will journal everything. > How could this be accomplished: > 1. Flush any dirty cache pages as soon as possible. There may > not be any > dirty cache after a certain amount of idle time. This can be done from user space. The simple approach would be to set up a cron job to sync and flush buffers every "n" seconds. A smarter approach would examine the load average, and not sync if the load was high. This does not need to be in the kernel. > 2. Keep open files in a state where it doesn't matter if they where > improperly closed (if possible). This is mostly a user space problem as well. It has been solved for editors which automatically save files every "n" minutes. I don't know if it can be solved from kernel space - if applications leave files in an inconsistent state, how can the kernel possibly do anything about it? > 3. Swap may not contain anything which can't be discarded. Otherwise > swap has to be treated as ordinary disk space. I'm not an expert, but I don't think this is relevant? > Don't we tell children never go close to any abyss or doesn't have > alpinist a saying "never go to the limits"? So why is this simple rule > always broken with computers? So were you breaking this rule? Were you using a journaling file system, or RAID, or a UPS? Torrey Hoffman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 should better cope with power failure
Brian Gerst wrote: > "Richard B. Johnson" wrote: > > > > On Mon, 19 Mar 2001, Otto Wyss wrote: > > > > > Lately I had an USB failure, leaving me without any access to my system > > > since I only use an USB-keyboard/-mouse. All I could do in that > > > situation was switching power off and on after a few minutes of > > > inactivity. From the impression I got during the following startup, I > > > assume Linux (2.4.2, EXT2-filesystem) is not very suited to any power > > > failiure or manually switching it off. Not even if there wasn't any > > > activity going on. > > > > > > Shouldn't a good system allways try to be on the save side? Shouldn't > > > Linux try to be more fail save? There is currently much work done in > > > getting high performance during high activity but it seems there is no > > > work done at all in getting a save system during low/no activity. I > > > think this is a major drawback and should be addressed as fast as > > > possible. Bringing a system to save state should allway have a high priority. > > > > > > How could this be accomplished: > > > 1. Flush any dirty cache pages as soon as possible. There may not be any > > > dirty cache after a certain amount of idle time. > > > 2. Keep open files in a state where it doesn't matter if they where > > > improperly closed (if possible). > > > 3. Swap may not contain anything which can't be discarded. Otherwise > > > swap has to be treated as ordinary disk space. > > > > > > These actions are not filesystem dependant. It might be that certain > > > filesystem cope better with power failiure than others but still it's > > > much better not to have errors instead to fix them. > > > > > > Don't we tell children never go close to any abyss or doesn't have > > > alpinist a saying "never go to the limits"? So why is this simple rule > > > always broken with computers? > > > > > > > Unix and other such variants have what's called a Virtual File System > > (VFS). The idea behind this is to keep as much recently-used file stuff > > in memory so that the system can be as fast as if you used a RAM disk > > instead of real physical (slow) hard disks. If you can't cope with this, > > use DOS. > > At the very least the disk should be consistent with memory. If the > dirty pages aren't written back to the disk (but not necessarily removed > from memory) after a reasonable idle period, then there is room for > improvement. They are. If you leave your machine one for a minute or so (probably less is ok, but I don't know) the kernel will flush dirty buffers... fsck will complain, but the file's *data* blocks will be on the disk. There are way more reasons that this is a silly and annoying thread. You should read more about things like asynchronous/synchronous filesystems, lazy-write cacheing, etc, etc,. If you know how to write software and/or configure your system, you can avoid all of these problems. Or use a journaling filesystem ext3/xfs, etc. But I tire of this... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 should better cope with power failure
"Richard B. Johnson" wrote: > > On Mon, 19 Mar 2001, Otto Wyss wrote: > > > Lately I had an USB failure, leaving me without any access to my system > > since I only use an USB-keyboard/-mouse. All I could do in that > > situation was switching power off and on after a few minutes of > > inactivity. From the impression I got during the following startup, I > > assume Linux (2.4.2, EXT2-filesystem) is not very suited to any power > > failiure or manually switching it off. Not even if there wasn't any > > activity going on. > > > > Shouldn't a good system allways try to be on the save side? Shouldn't > > Linux try to be more fail save? There is currently much work done in > > getting high performance during high activity but it seems there is no > > work done at all in getting a save system during low/no activity. I > > think this is a major drawback and should be addressed as fast as > > possible. Bringing a system to save state should allway have a high priority. > > > > How could this be accomplished: > > 1. Flush any dirty cache pages as soon as possible. There may not be any > > dirty cache after a certain amount of idle time. > > 2. Keep open files in a state where it doesn't matter if they where > > improperly closed (if possible). > > 3. Swap may not contain anything which can't be discarded. Otherwise > > swap has to be treated as ordinary disk space. > > > > These actions are not filesystem dependant. It might be that certain > > filesystem cope better with power failiure than others but still it's > > much better not to have errors instead to fix them. > > > > Don't we tell children never go close to any abyss or doesn't have > > alpinist a saying "never go to the limits"? So why is this simple rule > > always broken with computers? > > > > Unix and other such variants have what's called a Virtual File System > (VFS). The idea behind this is to keep as much recently-used file stuff > in memory so that the system can be as fast as if you used a RAM disk > instead of real physical (slow) hard disks. If you can't cope with this, > use DOS. At the very least the disk should be consistent with memory. If the dirty pages aren't written back to the disk (but not necessarily removed from memory) after a reasonable idle period, then there is room for improvement. -- Brian Gerst - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 for 2.5] preemptible kernel
Hi Pavel, Thanks for you comments. On Sat, 17 Mar 2001, Pavel Machek wrote: > > diff -Nur 2.4.2/arch/i386/kernel/traps.c linux/arch/i386/kernel/traps.c > > --- 2.4.2/arch/i386/kernel/traps.c Wed Mar 14 12:16:46 2001 > > +++ linux/arch/i386/kernel/traps.c Wed Mar 14 12:22:45 2001 > > @@ -973,7 +973,7 @@ > > set_trap_gate(11,&segment_not_present); > > set_trap_gate(12,&stack_segment); > > set_trap_gate(13,&general_protection); > > - set_trap_gate(14,&page_fault); > > + set_intr_gate(14,&page_fault); > > set_trap_gate(15,&spurious_interrupt_bug); > > set_trap_gate(16,&coprocessor_error); > > set_trap_gate(17,&alignment_check); > > Are you sure about this piece? Add least add a comment, because it > *looks* strange. With a preemptible kernel, we need to enter the page fault handler with interrupts disabled to protect the cr2 register. The interrupt state is restored immediately after cr2 has been saved. Otherwise, an interrupt could cause the faulting thread to be preempted, and the new thread could also fault, clobbering the cr2 register for the preempted thread. See the diff for linux/arch/i386/mm/fault.c. Nigel Gamble[EMAIL PROTECTED] Mountain View, CA, USA. http://www.nrg.org/ MontaVista Software [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB Mouse Problem in 2.4 Kernels - 2.2.18 Works Fine
> From: Andree Leidenfrost <[EMAIL PROTECTED]>
> To: Pete Zaitcev <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Date: 18 Mar 2001 22:50:32 +1100
>
> > > I am experiencing problems with a USB mouse: The machine boots, X
> > > starts, I log on, everything works as expected. When I restart X or just
> > > change to an alpha terminal and back to x the mouse does not work any
> > > more. [...]
> > > Hardware is an ASUS K7V motherboard (VIA chip set), [...]
> > > T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 5 Spd=1.5 MxCh= 0
> > Unfortunately, I do not have a hardware that exibits this.
> > If would be invaluable someone enabled
> > dbg() in devices/usb/hub.c only, [...]
> > [cable pulled, putting it back]
> > hub.c: port 1 connection change
> > hub.c: port 1, portstatus 301, change 1, 1.5 Mb/s
> > hub.c: port 1, portstatus 100, change 0, 12 Mb/s
> > hub.c: port 1 of hub 1 not enabled, trying reset again...
> Here is the output of a 2.2.18 kernel with the above patch:
>
> [cable pulled, putting it back]
> Mar 18 22:41:53 aurich kernel: hub.c: port 3 connection change
> Mar 18 22:41:53 aurich kernel: hub.c: portstatus 301, change 1, 1.5 Mb/s
> Mar 18 22:41:54 aurich kernel: hub.c: portstatus 303, change 10, 1.5 Mb/s
The following patch reverts the code path to that of 2.2 and fixes
the condition on the Andree's box:
--- linux-2.4.2-0.1.19/drivers/usb/hub.cTue Mar 13 12:04:05 2001
+++ linux-2.4.2-0.1.19-p3/drivers/usb/hub.c Mon Mar 19 12:03:42 2001
@@ -583,6 +583,12 @@
return;
}
+ /* zaitcev RHbug #23670 - 1.5Mb/s mice die when switching VCs */
+ if (portstatus & USB_PORT_STAT_LOW_SPEED) {
+ wait_ms(400);
+ delay = HUB_LONG_RESET_TIME;
+ }
+
down(&usb_address0_sem);
tempstr = kmalloc(1024, GFP_KERNEL);
I asked USB maintainers to consider it.
-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: pselect
>For people who prefer programming above documenting, >here is a simple small thing to do: > >POSIX.1g and Austin document a pselect() call intended to >remove the race condition that is present when one wants >to wait on either a signal or some file descriptor. >(See also Stevens, Unix Network Programming, Volume 1, 2nd Ed., >1998, p. 168 and the pselect.2 man page released today.) >Glibc 2.0 has a bad version (wrong number of parameters) >and glibc 2.1 a better version, but the whole purpose >of pselect is to avoid the race, and glibc cannot do that, >one needs kernel support. >So, probably someone should make a system call pselect >almost identical to the present select, adding a sigmask >parameter. (Or something more general.) Well, pselect is not that interesting I suppose, ppoll would be my favorite call to make use of. -- Jens-Uwe Mager mailto:62CFDB25> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sysrq.txt
On Mon, Mar 19, 2001 at 08:37:00PM +0100, J. Michael Kolbe wrote: > On Mon, Mar 19, 2001 at 09:15:59AM -0700, Tom Rini wrote: > > Speaking of reversed, there's a slightly "nicer" one in 2.2.18+: > > On PowerPC - You press 'ALT-Print Screen-'. > > > > (And yes, all the apple keyboards I've seen w/ F13 have Print Screen > > right below it). Tho I'm also rather sure this didn't get into > > Linus' tree until after the 2.3 split.. > > > Well, my Apple Keyboard doesn't. It's F13. And it doesn't work with 'ALT'. > I suppose that's why it didn't get into the mainstream tree. But anyways. My objects were it's not just "macs". And not all keyboards have "F13" written on them as well as Print Screen. Which is why I think what 2.2 has is what 2.4 should have. Or if yours doesn't say Print Screen: On PowerPC - You press 'ALT-Print Screen (or F13)- As to weather or not it's the key which says "ALT" on it or not, it is the key which provides the ALT keycode in linux. Or it very well should be, for consistencys sake. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 should better cope with power failure
On Mon, 19 Mar 2001, Otto Wyss wrote: > inactivity. From the impression I got during the following startup, I > assume Linux (2.4.2, EXT2-filesystem) is not very suited to any power > failiure or manually switching it off. Not even if there wasn't any > activity going on. What data, if any, did you lose? While fsck complains loudly when the system comes back up, 9 times in 10 no data is actually lost during a power loss. e2fsck is really good at recovering damaged filesystems. > How could this be accomplished: > 1. Flush any dirty cache pages as soon as possible. There may not be any > dirty cache after a certain amount of idle time. Mount the filesystem synchronously to accomplish this. It will prevent the kernel from using a write cache basically. It will ensure that if a write operation completes, then the data will be physically on the disk afterward. > 2. Keep open files in a state where it doesn't matter if they where > improperly closed (if possible). The way to do this is to use a highly reliable filesystem, such as ext3fs, Tux or ReiserFS. These filesystems guarantee that metadata is consistent at all times. > 3. Swap may not contain anything which can't be discarded. Otherwise > swap has to be treated as ordinary disk space. I can't think of a case where the contents of swap matter in any way for recovering from a power failure. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Utility for re-patritioning
Hello, try resize2fs from e2fsprogs package. B. -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: UDMA 100 / PIIX4 question
Jeremy Jackson wrote:
>
> Tim Moore wrote:
> > 15MB/s for hdparm is about right.
>
> Yes, since hdparm -t measures *SUSTAINED* transfers... the actual "head rate" of
>data reads from
> disk surface. Only if you read *only* data that is alread in harddrive's cache will
>you get a speed
> close to the UDMA mode of the drive/controller. The cache is around 1Mbyte, so for
>a split-second
> re-read of some data
Apologies for the too brief answer. Sustained real world transfer rates for the PIIX4
under ideal
setup conditions and a quiet bus are 14-18MB/s. Faster disk architecture and forcing
ide driver
parameters will not change this.
Here's what you might expect from this disk family with an ATA-66 capable chipset:
[tim@abit tim]# hdparm -i /dev/hda; hdparm -tT /dev/hda
/dev/hda:
Model=IBM-DTLA-307020, FwRev=TX3OA50C, SerialNo=YH0YHF45553
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40
BuffType=DualPortCache, BuffSize=1916kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=40188960
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 udma5
/dev/hda:
Timing buffer-cache reads: 128 MB in 0.81 seconds =158.02 MB/sec
Timing buffered disk reads: 64 MB in 1.85 seconds = 34.59 MB/sec
Larger sustained transfers are about 75% of the burst/cache influenced hdparm timings.
[tim@abit tim]# time dd if=/dev/hda of=/dev/null bs=1k count=500k
512000+0 records in
512000+0 records out
0.340u 6.780s 0:19.68 36.1% 0+0k 0+0io 115pf+0w
[tim@abit tim]# echo "512000/19.68" | bc -q
26016
--
| 650.390.9613 | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: UDMA 100 / PIIX4 question
> > > I have an IBM DTLA 307030 (ATA 100 / UDMA 5) on an 815e board (Asus CUSL2), >which has a PIIX4 controller. > > > ... > > > My problem is that (according to hdparm -t), I never get a better transfer rate >than approximately 15.8 Mb/sec > > > > 15MB/s for hdparm is about right. it's definitely not right: this disk sustains around 35 MB/s. > Yes, since hdparm -t measures *SUSTAINED* transfers... the actual "head rate" of >data reads from > disk surface. Only if you read *only* data that is alread in harddrive's cache will >you get a speed > close to the UDMA mode of the drive/controller. The cache is around 1Mbyte, so for >a split-second > re-read of some data nonsequitur: the controller and disk are both quite capable of sustaining 20-35 MB/s (depending on zone.) here's hdparm output for a disk of the same rpm and density as the DTLA's: Timing buffer-cache reads: 128 MB in 1.07 seconds =119.63 MB/sec Timing buffered disk reads: 64 MB in 2.02 seconds = 31.68 MB/sec (maxtor dm+45, hpt366 controller) regards, mark hahn. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: UDMA 100 / PIIX4 question
> You should be able to get about 30 MB/s at the start of the disk (zone 0) according
>to IBM's datasheet at
>
> http://ssdweb01.storage.ibm.com/techsup/hddtech/prodspec/dtla_spw.pdf
>
> so if you were testing say /dev/hda1 which is at the start of the disk it should be
>faster.
"should be" is yes and yes, but you will not see 30MB/s and there is no actual
difference between
/dev/hda and /dev/had1.
> Try hdparm -i /dev/hda (or whatever) .. . note the reported MaxMultSect= value,
> and put it in place of X in command:
>
> hdparm -u 1 -d 1 -m X -c 1 /dev/hda
I've spent more time with real world data transfer testing than god, both PIIX4-based
motherboards
and network based (Network Appliance <-> linux). The only hdparm parameter that makes
any
measurable, significnat difference for most modern drive and chipset combinations is
-d1 and the
correct UDMA mode.
Try partitioning your disk in 4 equal segments and run multiple tests in runlevel1 on
/dev/hda[1-4]
for '/usr/bin/time hdparm -tT' plus permutations of -a[0248]c[013]m[024816]u[01],
and /usr/bin/time dd if=/dev/hda[1-4] of=/dev/null bs=1k
count={32,64,128,256,512,1024}k.
rgds,
tim.
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sysrq.txt
On Mon, Mar 19, 2001 at 08:37:00PM +0100, J. Michael Kolbe wrote: > On Mon, Mar 19, 2001 at 09:15:59AM -0700, Tom Rini wrote: > > Speaking of reversed, there's a slightly "nicer" one in 2.2.18+: > > On PowerPC - You press 'ALT-Print Screen-'. > > > > (And yes, all the apple keyboards I've seen w/ F13 have Print Screen > > right below it). Tho I'm also rather sure this didn't get into > > Linus' tree until after the 2.3 split.. > > > Well, my Apple Keyboard doesn't. It's F13. And it doesn't work with 'ALT'. Which? And it should indeed work with the "alt" key (ie the one for changing VCs). > I suppose that's why it didn't get into the mainstream tree. Er, 2.2 is mainstream. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 should better cope with power failure
On Mon, 19 Mar 2001, Otto Wyss wrote: > Lately I had an USB failure, leaving me without any access to my system > since I only use an USB-keyboard/-mouse. All I could do in that > situation was switching power off and on after a few minutes of > inactivity. From the impression I got during the following startup, I > assume Linux (2.4.2, EXT2-filesystem) is not very suited to any power > failiure or manually switching it off. Not even if there wasn't any > activity going on. > > Shouldn't a good system allways try to be on the save side? Shouldn't > Linux try to be more fail save? There is currently much work done in > getting high performance during high activity but it seems there is no > work done at all in getting a save system during low/no activity. I > think this is a major drawback and should be addressed as fast as > possible. Bringing a system to save state should allway have a high priority. > > How could this be accomplished: > 1. Flush any dirty cache pages as soon as possible. There may not be any > dirty cache after a certain amount of idle time. > 2. Keep open files in a state where it doesn't matter if they where > improperly closed (if possible). > 3. Swap may not contain anything which can't be discarded. Otherwise > swap has to be treated as ordinary disk space. > > These actions are not filesystem dependant. It might be that certain > filesystem cope better with power failiure than others but still it's > much better not to have errors instead to fix them. > > Don't we tell children never go close to any abyss or doesn't have > alpinist a saying "never go to the limits"? So why is this simple rule > always broken with computers? > Unix and other such variants have what's called a Virtual File System (VFS). The idea behind this is to keep as much recently-used file stuff in memory so that the system can be as fast as if you used a RAM disk instead of real physical (slow) hard disks. If you can't cope with this, use DOS. Even Windows tries to emulate Unix as far as VFS is concerned. However Windows never reports any errors. By design, Windows keeps trashing along until you must reinstall it because there is nothing left of the file-system. If you want file-system trashing errors hidden, use Windows. Unix and its variants provide enough information in their file-systems to recover the file-system, although not necessaily a particular file, upon startup, if you have just switched the system off. It uses `fsck` for this. If as you say; "bringing the system to a save state should always have a high priority...", then mount the disks `sync`. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: UDMA 100 / PIIX4 question
Tim Moore wrote: > [EMAIL PROTECTED] wrote: > > I have an IBM DTLA 307030 (ATA 100 / UDMA 5) on an 815e board (Asus CUSL2), which >has a PIIX4 controller. > > ... > > My problem is that (according to hdparm -t), I never get a better transfer rate >than approximately 15.8 Mb/sec. I achieve this when DMA is enabled, - without it I >fall back to about 5 Mb /sec. No amount of fiddling with other hdparm settings makes >any difference. > > ... > > 15MB/s for hdparm is about right. You should be able to get about 30 MB/s at the start of the disk (zone 0) according to IBM's datasheet at http://ssdweb01.storage.ibm.com/techsup/hddtech/prodspec/dtla_spw.pdf so if you were testing say /dev/hda1 which is at the start of the disk it should be faster. Try hdparm -i /dev/hda (or whatever) .. . note the reported MaxMultSect= value, and put it in place of X in command: hdparm -u 1 -d 1 -m X -c 1 /dev/hda Cheers, Jeremy PS - please let me know if this fixed your problem, since I have a system with the same motherboard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
True multihead, lots of crashes
Hi, DUAL-Celeron, 2.4.0, ATI64 Rage pro AGP, Matrox Millenium, Matrox Mystique, ATI Rage II+ PCI, normal keyboard USB keyboard, 2x USB mouse. USB hub and USB hub in keyboard. 1. Just plain Xfree 4.0.2 with xinerama works stable, just gets killed by memory-hogging netscape. 2. framebuffer leads to hardlock sometimes quite soon. whatever, ati or matrox. Looks like at VT switch. No way to debug, 3. I have here second patched Xfree, got someones patch and rebuilt rpm, to support USB keyboard. the box crashes also without it. It looks like all places where VT switch may occur, are commented out from xfree. Without framebuffer, everything works, but vt switch still occurs and only one X is usable... first X stalls until second gets killed and then works again. sometimes I can even switch between them from console. Does the console input trigger console switch... dont understand. strace doesnt show anything ... looks like two copies of X talk each other via shared memory or something... elmer. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 should better cope with power failure
Otto Wyss <[EMAIL PROTECTED]> wrote: > Lately I had an USB failure, leaving me without any access to my system > since I only use an USB-keyboard/-mouse. All I could do in that > situation was switching power off and on after a few minutes of > inactivity. From the impression I got during the following startup, I > assume Linux (2.4.2, EXT2-filesystem) is not very suited to any power > failiure or manually switching it off. Not even if there wasn't any > activity going on. You're not using the filesystem the way you should, if you expect to be able to kill the power and not lose data. > How could this be accomplished: > 1. Flush any dirty cache pages as soon as possible. There may not be any > dirty cache after a certain amount of idle time. Mount the filesystem sychronously if you want this. > 2. Keep open files in a state where it doesn't matter if they where > improperly closed (if possible). Mount the filesystem read-only if you want this. > 3. Swap may not contain anything which can't be discarded. Otherwise > swap has to be treated as ordinary disk space. The kernel doesn't care about what's in swap. Fix your applications if they do. Charles -- --- Charles Cazabon<[EMAIL PROTECTED]> GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 0000 and 0002 on dual PIII 750 2.4.2 SMP platform
"Shane Y. Gibson" wrote: > > Marcelo Tosatti wrote: > > > > Did'nt you get a message similar to > > > > "kernel BUG at page_alloc.c line xxx!" Okay, I set the nmi_watchdog=0 options for LILO. Now on crashes, I get ZERO panic output in the log files. I found some old PII 450s, and don't seem to get any panics when I run the PII450s. I'll remove the nmi_watchdog option, and put the 750s back in, and see if I can get anymore panic output. v/r Shane -- Shane Y. Gibson [EMAIL PROTECTED] Network Architect(408) 447-8253 work IT Data Center Operations(650) 302-0193 cell Digital Impact, Inc. (408) 447-8298 fax "The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts." Bertrand Russell - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
atomic_set(skb_datarefp(skb),1)
Hi, I am extremely sorry to bother this group with this message. But I am really unable to understand the following. So it would be very kind of you if you clarify this. In 2.2.16, in the function alloc_skb(), atomic_set(skb_datarefp(skb),1) is there. Now skb_datarefp() returns skb->end casted in (atomic_t *) type. And atomic_set here setting it to 1. But before atomic_set() is called in alloc_skb(), skb->end is set to data+size. Now my question is what is the purpose of calling atomic_set()? regards sourav - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: UDMA 100 / PIIX4 question
Tim Moore wrote: > [EMAIL PROTECTED] wrote: > > I have an IBM DTLA 307030 (ATA 100 / UDMA 5) on an 815e board (Asus CUSL2), which >has a PIIX4 controller. > > ... > > My problem is that (according to hdparm -t), I never get a better transfer rate >than approximately 15.8 Mb/sec. I achieve this when DMA is enabled, - without it I >fall back to about 5 Mb /sec. No amount of fiddling with other hdparm settings makes >any difference. > > ... > > 15MB/s for hdparm is about right. Yes, since hdparm -t measures *SUSTAINED* transfers... the actual "head rate" of data reads from disk surface. Only if you read *only* data that is alread in harddrive's cache will you get a speed close to the UDMA mode of the drive/controller. The cache is around 1Mbyte, so for a split-second re-read of some data > > > "...four IDE devices can be supported in Bus Master mode. > PIIX4 contains support for "Ultra DMA/33" synchronous DMA > compatible devices." > > http://developer.intel.com/design/intarch/techinfo/440BX/PIIX4_intro.htm > > -- > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gettimeofday question
Russell King wrote: > > Eli Carter writes: > > Russell, I know that at least the EBSA285's timer1_gettimeoffset() needs > > some attention to fix a time going backward problem. > > I know about this, which is what started me looking at what x86 does, > and I am firmly of the conclusion that x86 is buggy as it stands. Ah, OK. > I believe that we can, instead of having a per-machine fix on ARM, have > a generic fix. At the moment, I haven't worked out exactly what this > generic fix would be. > > > The problem is only going to occur if gettimeoffset has not been called > > in the past 10ms. Once 10ms has passed, either jiffies has changed, or > > count will have passed count_p. > > My concern with the x86 fix is what if 9.99ms has passed since the > last timer tick, and we got the timer tick after we disabled interrupts and > entered do_gettimeofday. This can lead to the tests in there miscorrecting > IMHO. You won't see it with an infinite loop reading the time of day... Hmm... I'm not seeing it quite yet... do_gettimeofday doesn't -- disable interrupts for do_gettimeofday -- interrupt raised for "TIMER1" (or isa timer or whatever), the timer's counter wraps back to the value of LATCH and begins decrementing. -- we make a copy of xtime -- gettimeoffset is called. Assuming it has been called less than 10ms ago, (jiffies_t == jiffies_p && count > count_p) is true, so we adjust the 10ms for that, and return the number of usecs since the last jiffie change. -- add the offset, bringing us up to the correct time -- lost_ticks adjusts for the number of jiffies that have been counted but not added to xtime (and thus has no impact on the gettimeoffset logic) (so, shouldn't this be "tv->tv_usec += lost_ticks * USECS_PER_JIFFY;"? or can lost_ticks never be greater than 1?) -- restore interrupts -- jiffies & lost_ticks get incremented What are you seeing that I'm missing? > I'll re-read your mail in more depth later tonight. Appologies if this > reply appears to be a little early. No problem. I'd like to see this code fixed correctly, so I'm happy to help. C-ya, Eli ---. Rule of Accuracy: When working toward Eli Carter |the solution of a problem, it always eli.carter(at)inet.com `-- helps if you know the answer. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux should better cope with power failure
Lately I had an USB failure, leaving me without any access to my system since I only use an USB-keyboard/-mouse. All I could do in that situation was switching power off and on after a few minutes of inactivity. From the impression I got during the following startup, I assume Linux (2.4.2, EXT2-filesystem) is not very suited to any power failiure or manually switching it off. Not even if there wasn't any activity going on. Shouldn't a good system allways try to be on the save side? Shouldn't Linux try to be more fail save? There is currently much work done in getting high performance during high activity but it seems there is no work done at all in getting a save system during low/no activity. I think this is a major drawback and should be addressed as fast as possible. Bringing a system to save state should allway have a high priority. How could this be accomplished: 1. Flush any dirty cache pages as soon as possible. There may not be any dirty cache after a certain amount of idle time. 2. Keep open files in a state where it doesn't matter if they where improperly closed (if possible). 3. Swap may not contain anything which can't be discarded. Otherwise swap has to be treated as ordinary disk space. These actions are not filesystem dependant. It might be that certain filesystem cope better with power failiure than others but still it's much better not to have errors instead to fix them. Don't we tell children never go close to any abyss or doesn't have alpinist a saying "never go to the limits"? So why is this simple rule always broken with computers? O. Wyss - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: UDMA 100 / PIIX4 question
[EMAIL PROTECTED] wrote: > I have an IBM DTLA 307030 (ATA 100 / UDMA 5) on an 815e board (Asus CUSL2), which >has a PIIX4 controller. > ... > My problem is that (according to hdparm -t), I never get a better transfer rate than >approximately 15.8 Mb/sec. I achieve this when DMA is enabled, - without it I fall >back to about 5 Mb /sec. No amount of fiddling with other hdparm settings makes any >difference. > ... 15MB/s for hdparm is about right. "...four IDE devices can be supported in Bus Master mode. PIIX4 contains support for "Ultra DMA/33" synchronous DMA compatible devices." http://developer.intel.com/design/intarch/techinfo/440BX/PIIX4_intro.htm -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 to mount /proc/sys/fs/binfmt_misc ?
Alexander Viro <[EMAIL PROTECTED]> wrote:
>Seriously, binfmt_misc.c was written in rather, erm, interesting C.
>Read it and you'll see. Just one (but rather impressive) example:
>
>if ((count == 1) && !(buffer[0] & ~('0' | '1'))) {
>
>It was meant to be
>
>if (count == 1 && (buffer[0] == '0' || buffer[0] == '1')) {
>
>and anyone who can't find the difference really should learn C. And
>that's not the only bogosity of such level. Besides, the thing is
>trivially oopsable - write() to any file in binfmt_misc with buffer
>pointing to unmapped kernel address and you are screwed,
Or you can register binfmt names that are registered already and
silently shadow old ones, or register names like 'register', 'status',
'.', and '..'. It's hideous to manage reliably from userspace.
--
Colin Watson [[EMAIL PROTECTED]]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [CHECKER] 120 potential dereference to invalid pointers errors for linux 2.4.1
Well the ACPI bugs look legitimate. We'll work on getting those fixed. Thanks for your efforts! Regards -- Andy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gettimeofday question
Eli Carter writes: > Russell, I know that at least the EBSA285's timer1_gettimeoffset() needs > some attention to fix a time going backward problem. I know about this, which is what started me looking at what x86 does, and I am firmly of the conclusion that x86 is buggy as it stands. I believe that we can, instead of having a per-machine fix on ARM, have a generic fix. At the moment, I haven't worked out exactly what this generic fix would be. > The problem is only going to occur if gettimeoffset has not been called > in the past 10ms. Once 10ms has passed, either jiffies has changed, or > count will have passed count_p. My concern with the x86 fix is what if 9.99ms has passed since the last timer tick, and we got the timer tick after we disabled interrupts and entered do_gettimeofday. This can lead to the tests in there miscorrecting IMHO. You won't see it with an infinite loop reading the time of day... I'll re-read your mail in more depth later tonight. Appologies if this reply appears to be a little early. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please help
>I have a fundamental question: > >If I have to port LINUX on to new processor. How will I get address >mapping of different devices. Some of them are available in the manual. >Ex: NVram starting address is not available. >Iam porting on mips3k. Related question: does there exist any kind of definition of the abstract interface between the architecture-independent and architecture-dependent parts of the kernel? Or am I being naive? -- /Jonathan Lundell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rsync over ssh on 2.4.2 to 2.2.18
Hello! > Well, since I moved the rsync to 5pm, and then back to 9pm, I haven't > seen this problem - everything is again working as expected (touch wood) > with 2.2.15pre13 and 2.4.0. > > This is odd, since it wasn't a one-off problem, but something that happened > each and every day of a particular week. Anyway, if it starts happening > again, I'll get a tcpdump of the session. Well... I can reproduce this not depending of day of week now. :-( If I understood Andrew's mail correctly, rsync freezes when large amount of errors happen. Particularly, here ssh always freezes trying to write to stdout (pipe linked to rsync) some chunk of data (>64K), consisting of reports sort of "stat(usr/X11R6/bin/xmbind) : No such file" (my /usr has huge amount of stray symlinks...). rsync does not read this pipe, trying to write some more data to pipe, which is pipe linked to rsync stdin. Dead lock. Note, that doing strace you do not see this write()! write() is interrupted by strace and you see succesful select(). You can see real place of lockup via ps axl or starting strace before lockup happened. Andrew said about one more common case, when large amount of errors happens: wrong permission on some target directory. I have impression that long ago I observed the same affect, when disk space at target exhausted. Why do I tall this? Well, probably, something changed at fs, wich you rsync and rsync generates less errors. Alexey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Cisco 342 Driver
This is an "information pointer" request. I see there has been patching activity fairly recently for the aironet4800 drivers, but have been unable to successfully contact the maintainer listed in the sources. Is there anyone out in kernel-list land with this thing running on a PCI-based 340 series card, as opposed to PCMCIA? When I configure my kernel to include the various pieces of the driver inside the kernel (as opposed to as modules) the configure script will NOT let me configure the /proc interface inside the kernel too, complaining that it must be a module "to be consistent with the other configuration choices" I have made. That doesn't make sense. If I override that in .config, I get an OOPS when I boot up and first execute ifconfig on *any* network device. If I build the set as modules I get errors at module load time. Etc. I need either configuration information or a pointer to someone to talk to about this. Thanks. B. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
