Re: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1

[Linus Torvalds]

On Wed, 10 Jan 2001, Christoph Hellwig wrote:
> 
> Simple.  Because I stated before that I DON'T even want the networking
> to use kiobufs in lower layers.  My whole argument is to pass a kiovec
> into the fileop instead of a page, because it makes sense for other
> drivers to use multiple pages, and doesn't hurt networking besides
> the cost of one kiobuf (116k) and the processor cycles for creating
> and destroying it once per sys_sendfile.

Fair enough.

My whole argument against that is that I think kiovec's are incredibly
ugly, and the less I see of them in critical regions, the happier I am.

And that, I have to admit, is really mostly a matter of "taste". 

De gustibus non disputandum.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2/2.4 on MSI 694D Pro-AIR (MS-6321)

[Håvard Lygre]

Paul Flinders <[EMAIL PROTECTED]> writes:

> Has anyone got either 2.2.x or 2.4.0 booted on the above motherboard?

I've got an MSI 694D Pro AI mainboard (ie non-raid), and both 2.2.x
and 2.4.0 work flawlessly here.  I did manage to build a 2.4.0 kernel
which didn't boot, but it got much further before it hung.  I didn't
try to find out why, just changed some settings (removing APM/ACPI,
iirc), so I'm not sure why.


> This board has an integrated Promise Fasttrack ATA/100 controller - I
> know that to support the hardware RAID I need the binary only drivers
> from Promise but I'd rather not use these if software RAID works as
> there's no source, however I'm not getting that far.

My board doesn't have RAID, but it has a Promise PDC20627
ATA/100-controller, which is properly detected (although I haven't
tried to run it at UDMA 100-speeds, I can't see why it shouldn't as
long as the controller is supported) Currently there are no disks on
the promise controller, but I've tried that, and I know it works.


> PDC20265: IDE controller on PCI bus 00 dev 60
> PDC20265: Chipset Revision 2
> PDC20265: not 100% native mode: will probe irqs later
> PDC20265: (U)DMA Burst Bit ENABLED Primary MASTER Mode Secondary MASTER Mode.
> ide2: BM-DMA at 0xdc00-0xdc07, BIOS settings: hde:pio, hdf:pio
> 
> Then it hangs requiring power cycling.
> 
> I'm not sure whether the I/O address reported by the promise driver is
> correct - the promise BIOS shows the I/O address for the first channel
> as 0xCC00.

Here is my output from 2.4.0, SMP, same section:


Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686a IDE UDMA66 controller on pci0:7.1
ide0: BM-DMA at 0x9000-0x9007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0x9008-0x900f, BIOS settings: hdc:DMA, hdd:DMA
PDC20267: IDE controller on PCI bus 00 dev 60
PDC20267: chipset revision 2
PDC20267: not 100% native mode: will probe irqs later
PDC20267: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
ide2: BM-DMA at 0xac00-0xac07, BIOS settings: hde:DMA, hdf:pio
ide3: BM-DMA at 0xac08-0xac0f, BIOS settings: hdg:pio, hdh:DMA
hda: IBM-DTLA-307030, ATA DISK drive
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
hdc: IBM-DTTA-371010, ATA DISK drive
hdd: ST38641A, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=3737/255/63, UDMA(66)
hdc: 19746720 sectors (10110 MB) w/465KiB Cache, CHS=19590/16/63, UDMA(33)
hdd: 16809660 sectors (8607 MB) w/128KiB Cache, CHS=16676/16/63, UDMA(33)
Partition check:
 /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 < p5 p6 >
 /dev/ide/host0/bus1/target0/lun0: [PTBL] [1229/255/63] p1 p2 < p5 p6 p7 p8 >
 /dev/ide/host0/bus1/target1/lun0: p1


> Is this a configuration with known problems?

Unless it's either the RAID that's causing you problems, or the maxtor
drives, I don't know what could cause this.  I'm not sure which
BIOS-version is on my card, but I haven't touched it.


-- 
Håvard Lygre, [EMAIL PROTECTED]
Bergen IT-Teknikk ANS, Conrad Mohrsvei 11, 5068 Bergen
Tlf: 55 360773  Fax: 55 360774
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1

[Christoph Hellwig]

On Tue, Jan 09, 2001 at 01:26:44PM -0800, Linus Torvalds wrote:
> 
> 
> On Tue, 9 Jan 2001, Christoph Hellwig wrote:
> > > 
> > > Look at sendfile(). You do NOT have a "bunch" of pages.
> > > 
> > > Sendfile() is very much a page-at-a-time thing, and expects the actual IO
> > > layers to do it's own scatter-gather. 
> > > 
> > > So sendfile() doesn't want any array at all: it only wants a single
> > > page-offset-length tuple interface.
> > 
> > The current implementations does.
> > But others are possible.  I could post one in a few days to show that it is
> > possible.
> 
> Why do you bother arguing, when I've shown you that even if sendfile()
> _did_ do multiple pages, it STILL wouldn't make kibuf's the right
> interface. You just snipped out that part of my email, which states that
> the networking layer would still need to do better scatter-gather than
> kiobuf's can give it for multiple send-file invocations.

Simple.  Because I stated before that I DON'T even want the networking
to use kiobufs in lower layers.  My whole argument is to pass a kiovec
into the fileop instead of a page, because it makes sense for other
drivers to use multiple pages, and doesn't hurt networking besides
the cost of one kiobuf (116k) and the processor cycles for creating
and destroying it once per sys_sendfile.

Christoph

-- 
Whip me.  Beat me.  Make me maintain AIX.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

xircom_tulip + NFS hanging interface

[Pau]

I've been getting problems all along the pre-2.4 series and 2.4 itself
when I use NFS to play mp3 files with xmms.

The message in the logs is:
tulip.c: outl_CSR6 too many attempts,csr5=0x60208100

After a few times the network stops working and it only recovers with the
following sequence of commands:

ifdown eth0 && ifup eth0 && ifconfig eth0 -promisc

Without ifconfig eth0 -promisc it still doesn't get any packet.
I have to stop and start the interface too ad -prmisc doesn't work alone.
So this is the only sequence that works.

The modules loaded are:
Module  Size  Used by
nfs75136   1  (autoclean)
lockd  49680   1  (autoclean) [nfs]
sunrpc 59392   1  (autoclean) [nfs lockd]
ide-cd 26608   0  (autoclean)
cdrom  27104   0  (autoclean) [ide-cd]
rtc 5520   0  (unused)
ipchains   32544   0  (unused)
apm 9088   2
parport_pc 18880   1  (autoclean)
lp  5200   0  (autoclean)
parport27680   1  (autoclean) [parport_pc lp]
autofs 10784   1  (autoclean)
xircom_tulip_cb30832   1  (autoclean)
serial_cb   1360   0  (autoclean) (unused)
serial 43344   0  (autoclean) [serial_cb]
isa-pnp29040   0  (autoclean) [serial]
agpgart16960   0  (unused)
maestro26880   1
soundcore   3952   2  [maestro]
uhci   18672   0  (unused)
usbcore52304   2  [uhci]


Thanks for your help
Pau

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: VM subsystem bug in 2.4.0 ?

[Christoph Rohland]

Hi Linus,

Linus Torvalds <[EMAIL PROTECTED]> writes:

> I'd really like an opinion on whether this is truly legal or not? After
> all, it does change the behaviour to mean "pages are locked only if they
> have been mapped into virtual memory". Which is not what it used to mean.
> 
> Arguably the new semantics are perfectly valid semantics on their
> own, but I'm not sure they are acceptable.

I just checked SuS and they do not list SHM_LOCK as command at all.

> In contrast, the PG_realdirty approach would give the old behaviour of
> truly locked-down shm segments, with not significantly different
> complexity behaviour.
>
> What do other UNIXes do for shm_lock()?
> 
> The Linux man-page explicitly states for SHM_LOCK that
> 
>   The user must fault in any pages that are required to be present
>   after locking is enabled.
> 
> which kind of implies to me that the VM_LOCKED implementation is ok.

Yes.

> HOWEVER, looking at the HP-UX man-page, for example, certainly implies
> that the PG_realdirty approach is the correct one. 

Yes.

> The IRIX man-pages in contrast say
> 
>   Locking occurs per address space;
> multiple processes or sprocs mapping the area at different
> addresses each need to issue the lock (this is primarily an
> issue with the per-process page tables).
> 
> which again implies that they've done something akin to a VM_LOCKED
> implementation.

So Irix does something quite different. For Irix SHM_LOCK is a special
version of mlock...

> Does anybody have any better pointers, ideas, or opinions?

I think the VM_LOCKED approach is the best: 

- SuS does not specify anything, the different vendors do different
  things. So people using SHM_LOCK have to be aware that the details
  differ.
- Technically this is the fastest approach for attached segments: We
  do not scan the relevent vmas at all and by doing so we keep the
  overhead lowest. And I do not see a reason to use SHM_LOCK besides
  performance.

BTW I also have a patch appended which bumps the page count. Works
also, is also small, but we will have a higher soft fault rate with
that.

Greetings 
Christoph

diff -uNr 2.4.0/ipc/shm.c c/ipc/shm.c
--- 2.4.0/ipc/shm.c Mon Jan  8 11:24:39 2001
+++ c/ipc/shm.c Tue Jan  9 17:48:55 2001
@@ -121,6 +121,7 @@
 {
shm_tot -= (shp->shm_segsz + PAGE_SIZE - 1) >> PAGE_SHIFT;
shm_rmid (shp->id);
+   shmem_lock(shp->shm_file, 0);
fput (shp->shm_file);
kfree (shp);
 }
@@ -467,10 +468,10 @@
if(err)
goto out_unlock;
if(cmd==SHM_LOCK) {
-   shp->shm_file->f_dentry->d_inode->u.shmem_i.locked = 1;
+   shmem_lock(shp->shm_file, 1);
shp->shm_flags |= SHM_LOCKED;
} else {
-   shp->shm_file->f_dentry->d_inode->u.shmem_i.locked = 0;
+   shmem_lock(shp->shm_file, 0);
shp->shm_flags &= ~SHM_LOCKED;
}
shm_unlock(shmid);
diff -uNr 2.4.0/mm/shmem.c c/mm/shmem.c
--- 2.4.0/mm/shmem.cMon Jan  8 11:24:39 2001
+++ c/mm/shmem.cTue Jan  9 18:04:16 2001
@@ -310,6 +310,8 @@
}
/* We have the page */
SetPageUptodate (page);
+   if (info->locked)
+   page_cache_get(page);
 
 cached_page:
UnlockPage (page);
@@ -399,6 +401,32 @@
spin_unlock (>u.shmem_sb.stat_lock);
buf->f_namelen = 255;
return 0;
+}
+
+void shmem_lock(struct file * file, int lock)
+{
+   struct inode * inode = file->f_dentry->d_inode;
+   struct shmem_inode_info * info = >u.shmem_i;
+   struct page * page;
+   unsigned long idx, size;
+
+   if (info->locked == lock)
+   return;
+   down(>i_sem);
+   info->locked = lock;
+   size = (inode->i_size + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;
+   for (idx = 0; idx < size; idx++) {
+   page = find_lock_page(inode->i_mapping, idx);
+   if (!page)
+   continue;
+   if (!lock) {
+   /* release the extra count and our reference */
+   page_cache_release(page);
+   page_cache_release(page);
+   }
+   UnlockPage(page);
+   }
+   up(>i_sem);
 }
 
 /*

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.2.18: writing an R/O floppy

[Ulrich Windl]

Hi,

I don't know if it's possible to make fd a read-only device if the 
inserted media is write-protected, but I had a strange problem:

I had inserted a write protected floppy and accessed it via autofs as 
vfat in 2.2.18. It worked. Some time later it had expired (and I'm not 
sure whether I had changed floppies in the meantime).

When I tried an "mdel a:*", it did terminate without message, but a 
later "mdir a:" showed all the files there. The kernel had 
unsuccessfully tried to write to the floppy however.

It's a bit hard to reproduce that, but I could guess that the disc-
change ore write-protect status was not updated in some case.

Maybe it rings some bell for one of you; if not, never mind.

Regards,
Ulrich

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

some issues for 2.4.0

[Ulrich Windl]

Hello,

I have some issues on Linux-2.4.0:

During boot the (slightly modified, see later) kernel says:

<4>Linux version 2.4.0-NANO (root@elf) (gcc version 2.95.2 19991024 (release)) #1 Mon 
Jan 8 
22:04:48 MET 2001
[...]
<4>PCI: PCI BIOS revision 2.10 entry at 0xfb280, last bus=1
<4>PCI: Using configuration type 1
<4>PCI: Probing PCI hardware
<4>Unknown bridge resource 0: assuming transparent

??? What does the message above mean?

<4>PCI: Using IRQ router VIA [1106/0596] at 00:07.0
<6>Activating ISA DMA hang workarounds.

The DMI reports some funny values for my low-price board (the vendor
did not ship a DMI utility as Asus did for my old one):

<6>DMI 2.2 present.
<6>39 structures occupying 1055 bytes.
<6>DMI table at 0x000F0800.
<4>BIOS Vendor: Award Software International, Inc.
<4>BIOS Version: 4.51 PG
<4>BIOS Release: 06/19/00
<4>System Vendor: VIA Technologies, Inc..
<4>Product Name: VT82C693BX.
<4>Version  .
<4>Serial Number  .

??? Aren't they (above two lines) funny?

<4>Board Vendor: Shuttle Inc..
<4>Board Name: HOT-AV11 693-596-W977.
<4>Board Version: 2A6LGH2A.

[...]

As reported for 2.4.0-test12 there seems to be a problem timing events
within an interrupt (e.g. serial): The jitter is quite high. I'm
timing pulses generated from a GPS clock every second to estimate the
clock error. I'll show the first few updates.  Let's show some facts
first, and they state a suspect. The pair is seconds:nanoseconds
for the captured timestamps. My pulse is roughly 200ms+800ms:

979070631:649924277
979070632:49920873
979070633:649922851
979070634:49921630
979070635:649923125
979070636:49920800

??? Oops! Time jumped back!

979070633:354954544
979070633:754953483
979070635:354954708
979070635:754954209
979070637:354955615
979070637:754953649
979070639:354955938
979070639:754953328

??? Again!

979070637:59988575
979070637:459985921
979070639:59986981
979070639:459985930
979070641:59986854
979070641:459985908
979070643:59987006
979070643:459987393
979070645:59987262
979070645:136458168

979070642:765020874
979070643:165018428
979070644:765019464
979070645:165018406
979070646:765019339
979070647:165018295
979070648:765019475
979070649:165018274

979070646:470052764
979070646:870050956
979070648:470053050
979070648:870051264
979070650:470052609
979070650:870051691
979070652:470052047
979070652:870050772

979070650:175085546
979070650:575083574
979070652:175084550
979070652:575083463
979070654:175085050
979070654:575084190
979070656:175084787
979070656:575083420
979070658:175084652
979070658:251540985
979070655:880118226
979070656:280115991
979070657:880118654
979070658:280116032
979070659:880118844
979070660:280115978
979070661:880123413
979070662:280115897

979070659:585150248
979070659:985148519
979070661:585149737
979070661:985148498
979070663:585150396
979070663:985148476
979070665:585150361
979070665:985148365

979070663:290189552
979070663:690181048
979070665:290182834
979070665:690181774
979070667:290182445
979070667:690181783
979070669:290182466
979070669:690181672
979070671:290182951

I either think that some overflow happens, or that some spinlock is
really busy. You can find the patch used in
ftp://ftp.kernel.org/pub/linux/daemons/ntp/PPS/PPS-2.4.0-pre3.tar.bz2

My CPU is identified as:
elf:/tmp # cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 6
model name  : Celeron (Mendocino)
stepping: 5
cpu MHz : 501.149
cache size  : 128 KB
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 
mmx fxsr
bogomips: 999.42


Regards,
Ulrich

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] More compile warning fixes for 2.4.0

[Linus Torvalds]

On Wed, 10 Jan 2001, Andrea Arcangeli wrote:

> On Tue, Jan 09, 2001 at 01:31:35PM -0800, Linus Torvalds wrote:
> > don't have to worry about undocumented extensions etc.
> 
> Infact I don't blame gcc maintainers for that, but the standard. Ok, minor
> issue.

Yeah, and nothing we can do about it any more.. Oh, well.

The fact is that the 

case xxx: ;

syntax is fairly ugly, so I'd prefer the fixup patches to look more like

case xxx:
/* fallthrough */ ;
}

or something (or maybe just a "break" statement), just so that we don't
turn the poor C language into line noise (can anybody say "perl" ;)

I have to say, I think it was Pascal had this "no semicolon needed before
an 'end'" rule, and I always really hated that. The C statement rules make
a lo tmore sense, and requiring a statement after a case statement is
probably a very good requirement from a language standpoint. It's just not
very pretty - but adding a break or a comment will at least separate out
the colon and the semi-colon a bit.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Subtle MM bug

[Linus Torvalds]

On Wed, 10 Jan 2001, David Woodhouse wrote:
> 
> How does this affect embedded systems with no swap space at all?

The no-swap behaviour shoul dactually be pretty much identical, simply
because both 2.2 and 2.4 will do the same thing: just skip dirty pages in
the page tables because they cannot do anything about them.

That said, the _other_ VM differences in 2.4.x may obviously make a
difference, just not the sticky swap cache one..

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

USB Keyboards for x86/uhci in 2.4- kernels?

[Benson Chow]

Anyone tried using these beasts on a x86?

Anyway, what's happening:   In BIOS my USB keyboard works really poorly -
it almost seems scancodes get dropped left and right.  Ok, so I don't mind
too much, i'm sure BIOS has a very limited driver.  After booting
Microsoft's offerring, it would work fine after it installs its driver.
I also tried this same keyboard on a HPUX Visualize C3600 workstation and
it also works nicely.

However linux would never fix  this "scancode drop" syndrome even after
loading the hid or usbkbd driver.  Both my Via uhci USB motherboard and
PIIX3 USB motherboard exhibit this usb keyboard strangeness
with the hid or usbkbd driver is installed.  I think the PIIX3
motherboard's bios doesnt handle USB properly so it doesn't even work in
BIOS setup.  Any idea what's going on?  Is there some other driver or
utility I need to install/run to get it working?  Maybe just my bad bios?

BTW: my USB Mouse, and USB Printer seem to work nicely in 2.4.0-release.

USB KBD: NMB USB 104-key PC-Style
USB Mouse: Microsoft Intellimouse w/Intellieye 1.0, Logitech Optical Wheel
USB Printer: HP Deskjet 880C
USB Hub: Belkin 4-port
Intel 82437SB(?) PIIX3 and Via 82C686(?) USB controller

Working: Stock HPUX10.2 HP Visualize C3600 PARISC2 Workstation
Working: Microsoft Windows 98 First Edition on the Via.

Thanks!
-bc


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] Re: [BUGTRAQ] major security bug in reiserfs (may affect SuSE Linux)

[lloy0076]

No oops maybe, BUT if you setup an evil script to make so many that the various kernel 
structures got too full (or it filled the whole partition/disk up) then

And at 650Mhz my computer could do that quite easily...


DL
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [BUGTRAQ] major security bug in reiserfs (may affect SuSE Linux)

[John H. Robinson, IV]

On Wed, Jan 10, 2001 at 12:42:01AM +0100, Marc Lehmann wrote:
> 
> Basically, you do:
> 
> mkdir "$(perl -e 'print "x" x 768')"

[jaqque@osiris:/tmp/chk]% uname -a
Linux osiris 2.2.18 [classified] Sat Jan 6 11:19:04 PST 2001 i586 unknown
[jaqque@osiris:/tmp/chk]% mkdir "$(perl -e 'print "x" x 768')"
[jaqque@osiris:/tmp/chk]% ls -la
total 2
drwxrwxr-x3 jaqque   jaqque819 Jan  9 21:55 .
drwxrwxrwt   10 root root  371 Jan  9 21:54 ..
drwxrwxr-x2 jaqque   jaqque 35 Jan  9 21:55 x...
[jaqque@osiris:/tmp/chk]% rm -rf x*
[jaqque@osiris:/tmp/chk]% mkdir "$(perl -e 'print "x" x 4033')"
mkdir: cannot create directory `xx': File name too long
[jaqque@osiris:/tmp/chk]% mkdir "$(perl -e 'print "x" x 4032')"
[jaqque@osiris:/tmp/chk]% rm -rf x*
[jaqque@osiris:/tmp/chk]% mkdir "$(perl -e 'print "x" x 4032')"
mkdir: cannot create directory `xx': File exists
zsh: exit 255   mkdir "$(perl -e 'print "x" x 4032')"
[jaqque@osiris:/tmp/chk]% ls -la
total 4
drwxrwxr-x3 jaqque   jaqque   4083 Jan  9 21:56 .
drwxrwxrwt   10 root root  371 Jan  9 21:54 ..
[jaqque@osiris:/tmp/chk]% 


no oops, but a directory that cannot be removed.

-john

linux kernel 2.2.18 with reiserfs-3.5.29 patch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] major security bug in reiserfs (may affect SuSELinux)

[Alexander Viro]

On Tue, 9 Jan 2001, Chris Mason wrote:

> 
> 
> On Wednesday, January 10, 2001 02:32:09 AM +0100 Marc Lehmann <[EMAIL PROTECTED]> wrote:
> 
> >>> EIP; c013f911<=
> > Trace; c013f706 
> > Trace; c0136e01 
> 
> The buffer reiserfs is sending to filldir is big enough for
> the huge file name, so I think the real fix should be done in VFSland.
 
> But, in the interest of providing a quick, obviously correct fix, this

ITYM "band-aid"

> reiserfs only patch will refuse to create file names larger 
> than 255 chars, and skip over any directory entries larger than 
> 255 chars.

Chris, I seriously suspect that it's not that simple (read: trace is a
BS). 0x20b is just too large for filldir().

However, actual code really looks like the end of filldir(). If that's the
case we are deep in it - argument of filldir() gets screwed. buf, that is.
Since it happens after we've already done dereferencing of buf in filldir()
and we don't trigger them... Fsck knows. copy_to_user() and put_user() should
not be able to screw the kernel stack.

Marc, could you please get larger area before the point of oops + your
fs/readdir.c and send them to me? As much as I hate disassembling, it's
better than guessing the version of compiler you've used and flags you've
built with.

Another useful thing would be printk() of buf prior and post calls of
copy_to_user() and put_user() + value of  before these calls.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [LIH] Re: PROBLEMS: computer crash due to overfilling ramfs; iso9660 CD not read correctly

[Suresh Ramasubramanian]

Archan Paul rearranged electrons thusly:

> I faced the same problem when I patched 2.4.0test7 with reiserFS
> support. On my further correspondence with Alan Cox, he wrote that he is
> unwilling to listen about any "bug report for 2.4kernel", arising after
> patching kernel with some foreign code...
> Any comments? 
 
Simple comment: you misplaced the "quotes".  If you use third party patches
(and reiserfs, though fairly mainstream, _is_ a third party patch), you have to
ask the patch maintainer.  ReiserFS is not (as far as I know) part of the linux
kernel yet.

--suresh

-- 
Suresh Ramasubramanian  <-->  mallet  efn  org
EMail Sturmbannfuhrer, Lower Middle Class Unix Sysadmin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PROBLEMS: computer crash due to overfilling ramfs; iso9660 CD not read correctly

[Archan Paul]

I faced the same problem when I patched 2.4.0test7 with reiserFS
support. On my further correspondence with Alan Cox, he wrote that he is
unwilling to listen about any "bug report for 2.4kernel", arising after
patching kernel with some foreign code...

Any comments? 

Archan Paul
[EMAIL PROTECTED]


[EMAIL PROTECTED] wrote:
> 
> - Begin Hush Signed Message from [EMAIL PROTECTED] -
> 
> hello.
> i just compiled a 2.4.0 kernel from stable sources from ftp.us.kernel.org,
>  including reiserfs support from the reiserfs patch (www.namesys.com) .
> anyway, i compiled the ramfs (resizeable ramdisk) feature as a module, loaded
> the module, and mounted a directory and started copying.  i kept copying
> files onto it via 'cp' and after each copy, i would check the ram left using
> 'top'.  everything was fine until i had 500kb of ram left and i copied a
> 2mb file.  total freeze.  the only thing that would happen is my keystrokes
> would output to the screen, and i could also use ALT + F? to change terminals.
>  i used the reset button and everything was back to normal.  i don't know
> why that happened.
> my next problem is with data CD's (iso9660).  I had the same problem with
> 2.2.x kernels.  after mounting the data CD, it would list fine, but the
> data would be corrupted (BMP and TIFF images would appear with lines through
> them, sometimes not even recognized as images; mp3's would sound like they
> are combined).  the solution would be to 'umount' the directory, open the
> cd-rom a little, and close the tray.  after 'mount'ing it, hopefully it
> would be fine.  if not, just pop the drive open again, etc. until it worked.
> the distribution is slackware 7.1, but most of my software is hand-compiled.
>  i read the REPORTING-BUGS file, and here is some of system info ( i hope
> it isn't overkill; i'm sorry if it is):
> 'dmesg' output:
> Linux version 2.4.0 (root@darkstar) (gcc version egcs-2.91.66 19990314/Linux
> (egcs-1.1.2 release)) #1 Tue Jan 9 18:50:51 EST 2001
> BIOS-provided physical RAM map:
>  BIOS-e820: 0009fc00 @  (usable)
>  BIOS-e820: 0400 @ 0009fc00 (reserved)
>  BIOS-e820: 0002 @ 000e (reserved)
>  BIOS-e820: 01f0 @ 0010 (usable)
>  BIOS-e820: 1000 @ fec0 (reserved)
>  BIOS-e820: 1000 @ fee0 (reserved)
>  BIOS-e820: 0002 @ fffe (reserved)
> On node 0 totalpages: 8192
> zone(0): 4096 pages.
> zone(1): 4096 pages.
> zone(2): 0 pages.
> Kernel command line: BOOT_IMAGE=new ro root=306
> Initializing CPU#0
> Detected 233.296 MHz processor.
> Console: colour VGA+ 80x30
> Calibrating delay loop... 465.30 BogoMIPS
> Memory: 30236k/32768k available (909k kernel code, 2144k reserved, 288k
> data, 196k 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: 008001bf  , vendor = 0
> Intel Pentium with F0 0F bug - workaround enabled.
> CPU: After vendor init, caps: 008001bf   
> CPU: After generic, caps: 008001bf   
> CPU: Common caps: 008001bf   
> CPU: Intel Pentium MMX stepping 03
> Checking 'hlt' instruction... OK.
> POSIX conformance testing by UNIFIX
> PCI: PCI BIOS revision 2.10 entry at 0xfdb11, last bus=0
> PCI: Using configuration type 1
> PCI: Probing PCI hardware
> isapnp: Scanning for Pnp cards...
> isapnp: Calling quirk for 01:00
> isapnp: SB audio device quirk - increasing port range
> isapnp: Card 'Creative ViBRA16X PnP'
> isapnp: 1 Plug & Play card detected total
> Linux NET4.0 for Linux 2.4
> Based upon Swansea University Computer Society NET3.039
> Starting kswapd v1.8
> pty: 256 Unix98 ptys configured
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> ALI15X3: IDE controller on PCI bus 00 dev 58
> PCI: No IRQ known for interrupt pin A of device 00:0b.0. Please try using
> pci=biosirq.
> ALI15X3: chipset revision 32
> ALI15X3: not 100% native mode: will probe irqs later
> ALI15X3: simplex device:  DMA disabled
> ide0: ALI15X3 Bus-Master DMA disabled (BIOS)
> ALI15X3: simplex device:  DMA disabled
> ide1: ALI15X3 Bus-Master DMA disabled (BIOS)
> hda: IBM-DTTA-351010, ATA DISK drive
> hdd: CREATIVEDVD-ROM DVD2240E 12/24/97, ATAPI CDROM drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> hda: 19807200 sectors (10141 MB) w/466KiB Cache, CHS=1232/255/63
> Partition check:
>  hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 >
> Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI
> ISAPNP enabled
> ttyS00 at 0x03f8 (irq = 4) is a 16550A
> ttyS01 at 0x02f8 (irq = 

Re: [PATCH] 2.4.0 MAINTAINERS for ide-floppy updates

[Andre Hedrick]

This is valid that Paul is maintaining that subdriver as GADI is doing a
StartUp in Video stuff.

Cheers,

On Tue, 9 Jan 2001, Paul Bristow wrote:

> Linus, Alan,
> 
> Could you please apply this patch to the MAINTAINERS file so that the
> 2.4.x
> IDE-FLOPPY maintainer is correctly identified as me and not Gadi any
> more.
> This change happened at 2.2.18 for the 2.2.x tree.
> 
> I am discussing with Sam the previous patch that Alan applied in
> 2.4.0-ac4 for 1.44M floppy formatting in LS-120 drives.
> 
> Regards,
> 
> -- 
> 
> Paul
> 
> Email:[EMAIL PROTECTED]
> Web:  http://paulbristow.net
> ICQ:  11965223
> 
> 
> Patch follows
> 
> diff -ur linux-2.4.0/MAINTAINERS linux/MAINTAINERS
> --- linux-2.4.0/MAINTAINERS Sun Dec 31 18:31:15 2000
> +++ linux/MAINTAINERS   Tue Jan  9 23:20:48 2001
> @@ -594,9 +594,16 @@
>  W: http://www.kernel.dk
>  S: Maintained
>  
> -IDE/ATAPI TAPE/FLOPPY DRIVERS
> +IDE/ATAPI TAPE DRIVERS
>  P: Gadi Oxman
>  M: Gadi Oxman <[EMAIL PROTECTED]>
> +L: [EMAIL PROTECTED]
> +S: Maintained
> +
> +IDE/ATAPI FLOPPY DRIVERS
> +P: Paul Bristow
> +M: Paul Bristow <[EMAIL PROTECTED]>
> +W: http://paulbristow.net/linux/idefloppy.html
>  L: [EMAIL PROTECTED]
>  S: Maintained
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
> 

Andre Hedrick
Linux ATA Development

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] ide-features.c: unchecked kmalloc

[Andre Hedrick]

Please name a time or event when you would cal a setfeaturers command
without having a IDENTIFY page filled?



On Tue, 9 Jan 2001, Arnaldo Carvalho de Melo wrote:

> Hi,
> 
>   Please consider applying.
> 
> - Arnaldo
> 
> --- linux-2.4.0-ac4/drivers/ide/ide-features.cMon Jan  8 20:39:17 2001
> +++ linux-2.4.0-ac4.acme/drivers/ide/ide-features.c   Tue Jan  9 16:02:11 2001
> @@ -189,6 +189,10 @@
>   __cli();/* local CPU only; some systems need this */
>   SELECT_MASK(HWIF(drive), drive, 0);
>   id = kmalloc(SECTOR_WORDS*4, GFP_ATOMIC);
> + if (!id) {
> + __restore_flags(flags); /* local CPU only */
> + return 0;
> + }
>   ide_input_data(drive, id, SECTOR_WORDS);
>   (void) GET_STAT();  /* clear drive IRQ */
>   ide__sti(); /* local CPU only */
> 

Andre Hedrick
Linux ATA Development

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: DRI doesn't work on 2.4.0 but does on prerelease-ac5

[Alan Olsen]

On Wed, 10 Jan 2001, Alan Cox wrote:

> >  The Mesa package in Red Hat 7 won't do DRI with recent XFree86 CVS.
> 
> Yep. Its Mesa 3.3/DRI 1.0. XFree86 CVS is Mesa 3.4/DRI 2.0. That has several
> advantages including mostly working on Matrox cards which 1.0 never did (for
> me anyway) and handling things that Mesa 3.3 tried to allocate the odd gig
> of ram for and then exploded.
> 
> With the CVS stuff the 2.4 kernel should work out of the box. You need -ac for
> some ALi AGP chipsets.

My experiences with the Matrox G400 has been similar.

With 4.0.1 and the Matrox drivers, I could get DRI to work... For a while
and then the whole thing would lock tight as a drum, kernel and all.

The Matrox drivers on their ftp site will not even build with
XFree86 4.0.2. 

XFree86 4.0.2 with 2.4.0-test 12 no longer locks up on some GL games.
(Heavy Gear II, Quake III, and Heretic 2 all work well.) The only
exception I can find is Descent 3 which has a nasty visual smearing
problem that makes it unplayable. (Not certain why. Have not pressed the
issue with Loki yet.) Xinerama has an odd problem, which Keith Packard is
looking into. (When he gets back from Hawaii.) Xinerama is usable, but has
some ugly screen artifacts on the second screen.

The other big difference between 4.0.1 under the 2.2.17 with back-ported
AGP and the 4.0.2 on 2.4.0-test 12 is that I now get a contant frame rate.
On the earlier version, the framerate could bounce around 25% of the total
frames with the Mesa gears test.  The new version I see a varience of
about 2 frames or so! VERY steady.

I will be testing the performance under 2.4.0 final sometime later
tonight, after I am done with the project I am currently working on.  (One
of those "I have an idea and must test it now" kinda days.  So far, the
code has all worked...)  

[EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply
Alan Olsen| to my mail, just hit the ctrl, alt and del keys.
"In the future, everything will have its 15 minutes of blame."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Patch: linux-2.4.0-pre1/arch/i386/i386_ksyms.c needs to export mmu_cr4_features

[Adam J. Richter]

linux-2.4.1-pre1/drivers/md/xor.c calls the macro XOR_TRY_TEMPLATES,
which is defined in include/asm-i386/xor.h to use HAVE_XMM, which is
defined in include/asm-i386/processor.h to reference mmu_cr4_features.
So, to support compilation of raid5 as a module, i386_ksyms.c needs
to export mmu_cr4_features.  I have attached the one line patch below.

Let me also add that 2.4.1-pre1 so far has been really smooth
sailing.  The problems with 2.4.0 hanging on the Sony PictureBook PCG-C1VN
have somehow disappeared with this version, usb-uhci.c does not generate
a kernel oops on that hardware, and this minor addition to i386_ksyms.c
was the only change that I had to make to get a clean build.  Hooray!

-- 
Adam J. Richter __ __   4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /  San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l   United States of America
fax +1 408 261-6631  "Free Software For The Rest Of Us."


--- linux-2.4.1-pre1/arch/i386/kernel/i386_ksyms.c  Wed Dec  6 21:00:12 2000
+++ linux/arch/i386/kernel/i386_ksyms.c Tue Jan  9 15:46:14 2001
@@ -49,6 +50,7 @@
 
 /* platform dependent support */
 EXPORT_SYMBOL(boot_cpu_data);
+EXPORT_SYMBOL(mmu_cr4_features);
 #ifdef CONFIG_EISA
 EXPORT_SYMBOL(EISA_bus);
 #endif

PROBLEMS: computer crash due to overfilling ramfs; iso9660 CD not read correctly

[noodlez]

- Begin Hush Signed Message from [EMAIL PROTECTED] -

hello.
i just compiled a 2.4.0 kernel from stable sources from ftp.us.kernel.org,
 including reiserfs support from the reiserfs patch (www.namesys.com) .
anyway, i compiled the ramfs (resizeable ramdisk) feature as a module, loaded
the module, and mounted a directory and started copying.  i kept copying
files onto it via 'cp' and after each copy, i would check the ram left using
'top'.  everything was fine until i had 500kb of ram left and i copied a
2mb file.  total freeze.  the only thing that would happen is my keystrokes
would output to the screen, and i could also use ALT + F? to change terminals.
 i used the reset button and everything was back to normal.  i don't know
why that happened.
my next problem is with data CD's (iso9660).  I had the same problem with
2.2.x kernels.  after mounting the data CD, it would list fine, but the
data would be corrupted (BMP and TIFF images would appear with lines through
them, sometimes not even recognized as images; mp3's would sound like they
are combined).  the solution would be to 'umount' the directory, open the
cd-rom a little, and close the tray.  after 'mount'ing it, hopefully it
would be fine.  if not, just pop the drive open again, etc. until it worked.
the distribution is slackware 7.1, but most of my software is hand-compiled.
 i read the REPORTING-BUGS file, and here is some of system info ( i hope
it isn't overkill; i'm sorry if it is):
'dmesg' output:
Linux version 2.4.0 (root@darkstar) (gcc version egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release)) #1 Tue Jan 9 18:50:51 EST 2001
BIOS-provided physical RAM map:
 BIOS-e820: 0009fc00 @  (usable)
 BIOS-e820: 0400 @ 0009fc00 (reserved)
 BIOS-e820: 0002 @ 000e (reserved)
 BIOS-e820: 01f0 @ 0010 (usable)
 BIOS-e820: 1000 @ fec0 (reserved)
 BIOS-e820: 1000 @ fee0 (reserved)
 BIOS-e820: 0002 @ fffe (reserved)
On node 0 totalpages: 8192
zone(0): 4096 pages.
zone(1): 4096 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=new ro root=306
Initializing CPU#0
Detected 233.296 MHz processor.
Console: colour VGA+ 80x30
Calibrating delay loop... 465.30 BogoMIPS
Memory: 30236k/32768k available (909k kernel code, 2144k reserved, 288k
data, 196k 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: 008001bf  , vendor = 0
Intel Pentium with F0 0F bug - workaround enabled.
CPU: After vendor init, caps: 008001bf   
CPU: After generic, caps: 008001bf   
CPU: Common caps: 008001bf   
CPU: Intel Pentium MMX stepping 03
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
PCI: PCI BIOS revision 2.10 entry at 0xfdb11, last bus=0
PCI: Using configuration type 1
PCI: Probing PCI hardware
isapnp: Scanning for Pnp cards...
isapnp: Calling quirk for 01:00
isapnp: SB audio device quirk - increasing port range
isapnp: Card 'Creative ViBRA16X PnP'
isapnp: 1 Plug & Play card detected total
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ALI15X3: IDE controller on PCI bus 00 dev 58
PCI: No IRQ known for interrupt pin A of device 00:0b.0. Please try using
pci=biosirq.
ALI15X3: chipset revision 32
ALI15X3: not 100% native mode: will probe irqs later
ALI15X3: simplex device:  DMA disabled
ide0: ALI15X3 Bus-Master DMA disabled (BIOS)
ALI15X3: simplex device:  DMA disabled
ide1: ALI15X3 Bus-Master DMA disabled (BIOS)
hda: IBM-DTTA-351010, ATA DISK drive
hdd: CREATIVEDVD-ROM DVD2240E 12/24/97, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 19807200 sectors (10141 MB) w/466KiB Cache, CHS=1232/255/63
Partition check:
 hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 >
Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI
ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
SCSI subsystem driver Revision: 1.00
scsi0 : AdvanSys SCSI 3.2M: PCI Ultra 240 CDB: IO EC00/F, IRQ 11
  Vendor: YAMAHAModel: CRW8424S  Rev: 1.0g
  Type:   CD-ROM ANSI SCSI revision: 02
  Vendor: UMAX  Model: Astra 2200Rev: V2.2
  Type:   ScannerANSI SCSI revision: 02
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured 

Re: [reiserfs-list] major security bug in reiserfs (may affect SuSE Linux)

[David Ford]

Why not use the limits from  instead?

-d

Chris Mason wrote:

> On Wednesday, January 10, 2001 02:32:09 AM +0100 Marc Lehmann <[EMAIL PROTECTED]> wrote:
>
> >>> EIP; c013f911<=
> > Trace; c013f706 
> > Trace; c0136e01 
>
> The buffer reiserfs is sending to filldir is big enough for
> the huge file name, so I think the real fix should be done in VFSland.
>
> But, in the interest of providing a quick, obviously correct fix, this
> reiserfs only patch will refuse to create file names larger
> than 255 chars, and skip over any directory entries larger than
> 255 chars.
>
> --- linux/include/linux/reiserfs_fs.h.1 Tue Jan  9 21:56:18 2001
> +++ linux/include/linux/reiserfs_fs.h   Tue Jan  9 21:56:33 2001
> @@ -467,7 +467,7 @@
>  /* name by bh, ih and entry_num */
>  #define B_I_E_NAME(entry_num,bh,ih) ((char *)(bh->b_data + ih->ih_item_location + 
>(B_I_DEH(bh,ih)+(entry_num))->deh_location))
>
> -#define REISERFS_MAX_NAME_LEN(block_size) (block_size - BLKH_SIZE - IH_SIZE - 
>DEH_SIZE)/* -SD_SIZE when entry will contain stat data */
> +#define REISERFS_MAX_NAME_LEN(block_size) 255
>
>  /* this structure is used for operations on directory entries. It is not a disk 
>structure. */
>  /* When reiserfs_find_entry or search_by_entry_key find directory entry, they 
>return filled reiserfs_dir_entry structure */
> --- linux/fs/reiserfs/dir.c.1   Tue Jan  9 22:06:06 2001
> +++ linux/fs/reiserfs/dir.c Tue Jan  9 22:15:17 2001
> @@ -159,6 +159,10 @@
> d_name = B_I_DEH_ENTRY_FILE_NAME (bh, ih, deh);
> d_off = deh->deh_offset;
> d_ino = deh->deh_objectid;
> +   if (d_reclen > REISERFS_MAX_NAME_LEN(inode->i_sb->s_blocksize)){
> +   /* it is too big to send back to VFS */
> +   continue ;
> +   }
> if (d_reclen <= 32) {
> local_buf = small_buf ;
> } else {
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

-- ---NOTICE

-- fwd: fwd: fwd: type emails will be deleted automatically.
  "There is a natural aristocracy among men. The grounds of this are
  virtue and talents", Thomas Jefferson [1742-1826], 3rd US President



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: DRI doesn't work on 2.4.0 but does on prerelease-ac5

[Alan Cox]

>  The Mesa package in Red Hat 7 won't do DRI with recent XFree86 CVS.

Yep. Its Mesa 3.3/DRI 1.0. XFree86 CVS is Mesa 3.4/DRI 2.0. That has several
advantages including mostly working on Matrox cards which 1.0 never did (for
me anyway) and handling things that Mesa 3.3 tried to allocate the odd gig
of ram for and then exploded.

With the CVS stuff the 2.4 kernel should work out of the box. You need -ac for
some ALi AGP chipsets.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: kNFSd maintenance in 2.2.19pre

[Neil Brown]

On Monday January 1, [EMAIL PROTECTED] wrote:
> On Thu, Dec 21, 2000 at 12:05:41PM +1100, Neil Brown wrote:
> >  So, I have started putting some patches together and they can be
> >  found at
> > http://www.cse.unsw.edu.au/~neilb/patches/knfsd-2.2/
> 
> I included the interesting ones in my tree.

But aren't they all interesting :-)

I've up-dated and re-organised them and added some more.  The new set
can be found at 
  http://www.cse.unsw.edu.au/~neilb/patches/knfsd-2.2/2.2.19-pre7

There is a list of the patches below. 
I plan to send (most of) the to Alan shortly.

> 
> Here two fixes against the vfs backport:
> 
> --- ./fs/nfsd/vfs.c.~1~   Fri Dec 29 18:02:01 2000
> +++ ./fs/nfsd/vfs.c   Mon Jan  1 18:09:46 2001
> @@ -1603,9 +1603,11 @@
>   eof = !cd.eob;
>  
>   if (cd.offset) {
> +#ifdef CONFIG_NFSD_V3
>   if (rqstp->rq_vers == 3)
>   (void)enc64(cd.offset, file.f_pos);
>   else
> +#endif /* CONFIG_NFSD_V3 */
>   *cd.offset = htonl(file.f_pos);
>   }

I deliberately removed the #ifdef here because I don't like ifdefs (I
have learned from the master) and this one wan't really needed.
Ofcourse, it may not compile like this unless you change "enc64" to
"xdr_encode_hyper" as a later patch did.

>  
> @@ -1624,6 +1626,7 @@
>   return err;
>  
>  out_nfserr:
> + up(>i_sem);
>   err = nfserrno(-err);
>   goto out_close;
>  }

Oops. Thanks for catching this.

NeilBrown

  From my web page: http://www.cse.unsw.edu.au/~neilb/patches/knfsd-2.2

2.2.19-pre7
  Last Changed: 10 January 2001, 2:52pm GMT--11 Click me for more detailed 
patch descriptions

 

 patch-A-maint
Update the MAINTAINERS file
 patch-B-sema
Broaden the range of effect of the s_nfsd_free_path_sem semphore
 patch-C-access
Allow ACCESS checks on special files - plus bug fix
 patch-D-nfsirix
Make nfsd treat devices/pipes in a way that works with IRIX
 patch-E-wdelay
Modify the wdelay handling
 patch-F-stablewrite
Tidyup communication of stable-write flag - backport from 2.4
 patch-G-errtidy
Tidy up handling of error codes - back port from 2.4
 patch-H-dotent
move define oif dotent and change memcpyto xdr_encode_string
 patch-I-backport
Further back port of bits and pieces from 2.4
 patch-J-return
backport changes to RETURN macros in nfs*proc.c
 patch-K-enc64
replace enc64/dec64 by xdr_encode_hyper/xdr_decode_hyper
 patch-L-noigetinuse
Remove iget_in_use
 patch-M-hash
Calculate hash correctly for new names
 patch-N-arrangedentry
Tidy up the choosing of a dentry given an inode.
 patch-O-backportvfs
backport some 2.4 changes to vfs.c
 patch-P-create
modify exclusive create to not return negative times
 patch-Q-dotdot
move guard against creating dot or dotdot earlier
 patch-R-noexperiment
Remove 'experimental' tag from nfsv3 server support
 patch-S-setport
allow explicit setting of port number for lockd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: DRI doesn't work on 2.4.0 but does on prerelease-ac5

[Bill Crawford]

 The Mesa package in Red Hat 7 won't do DRI with recent XFree86 CVS.
Michael is quite right in saying he needed to blow it away. The only
way I could get DRI working until recently was to transplant a copy
of libGL.so from the XFree86 build tree into /usr/lib, delete or rename
the Mesa package version out of the way, and run ldconfig.

 This is being fixed in Red Hat Raw Hide, and someone put up a version
for download (can't remember where now; will have a look tomorrow and
let you know).

-- 
/* Bill Crawford, Unix Systems Developer, ebOne, formerly GTS Netcom */
#include "stddiscl.h"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: storage over IP (was Re: [PLEASE-TESTME] Zerocopy networking patch,

[Cacophonix]

I haven't tracked the IP storage group too closely, but was at the San Diego IETF
where there were some interesting debates about this issue. 

There is a write-up at http://ips.pdl.cs.cmu.edu/mail/msg02598.html

Now I'm not sure if I agree with some of the assumptions. And I share your concern 
about using multiple tcp streams.

Thoughts?

cheers,
karthik


--- Alan Cox <[EMAIL PROTECTED]> wrote:
> > 
> > show that both use TCP/IP.  TCP/IP has variable length headers (or am i on
> > crack?), which totally complicates the receive path.
> 
> TCP has variable length headers. It also prevents you re-ordering commands
> in the stream which would be beneficial. I've not checked if the draft uses
> multiple TCP streams but then you have scaling questions. 
> 
> Alan
> 


__
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: .br blacklisted ?

[David Ford]

Rik van Riel wrote:

> On Sun, 7 Jan 2001, John O'Donnell wrote:
>
> > Only on my company's e-mail server.  My company typically gets "zero"
> > emails from outside the US.  If I get a piece of spam (sorry they are
> > typically from outside the US), I just block the entire .com.br domain.
> > I get far less SPAM now!
>
> Remind me to never help you with kernel problems again.

Others on this list blacklist or let others blacklist for them with varying
precision.  Sooner or later everyone is going to be blacklisting everyone
else until it's a daily thing here and no developer or user can talk to any
other devloper or user.

-d


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[Fwd: Learn from minix: fork ramfs.] - linus's ACTUAL reply.

[Rob Landley]

Okay, the sleep situation has not improved.  I'll admit that right now. 
But it's ABOUT to.  G'night...

Rob




On Mon, 8 Jan 2001, Rob Landley wrote:
> 
> So fork ramfs already.  Copy the snapshot you like as an educational
> tool, call it skeletonfs.c or some such, and let the current code evolve
> into something more useful.

The thing is, that I'm not sure that even the extended ramfs is really
useful except for very controlled environments (ie initrd-type things
where the contents of the ramdisk is _controlled_, and as such the
addition of limits is not necessarily all that useful a feature). Others
have spoken up on why tmpfs isn't a good thing either, with good
arguments.

So it's not all about teaching.

I think the ramfs limit code has a good argument from Alan for embedded
devices, so that probably will make it in. However, even so it's obviously
not a 2.4.1 issue, AND as shown by the fact that apparently the thing is
buggy and still worked on I wouldn't want the patches right now in the
first place.

Linus

[Fwd: Learn from minix: fork ramfs.] - linus's reply

[Rob Landley]

He replied to my bad cc:, so forwarding this here should be okay...


Linus Torvalds wrote:
> 
> On Mon, 8 Jan 2001, Rob Landley wrote:
> >
> > So fork ramfs already.  Copy the snapshot you like as an educational
> > tool, call it skeletonfs.c or some such, and let the current code evolve
> > into something more useful.
> 
> The thing is, that I'm not sure that even the extended ramfs is really
> useful except for very controlled environments (ie initrd-type things
> where the contents of the ramdisk is _controlled_, and as such the
> addition of limits is not necessarily all that useful a feature). Others
> have spoken up on why tmpfs isn't a good thing either, with good
> arguments.

I've got a use for it.  Diskless render nodes.

At my day job we do (among other things) rackmounted render farms, and
we're thinking about adding diskless dual procs to our line in our
Copious Free Time (tm).  The plan right now is to throw at least half a
gig of ram in each machine (quite possibly more, maya and other
renderers positively suck the stuff down even WITH local disks), boot
the sucker up via intel's PXE (dhcp/bootp/mtftp apparently has a new
name since last I saw it, right...), and use a combination of NFS and
ramfs for the root filesystem.

Ramfs is WAY better than the ram block device 'cause of the
auto-scaling.  If the client wants to use all the memory for the
rendering app, ramfs is only really dealing with logs and such.  If they
want to copy their dataset over and belch out frame after frame from the
local copy to cut down on server bandwidth (which can EASILY get to be a
bottleneck here).

Best of all, they don't have to come back to US to get any kind of
configuration changes, this is all a matter of what their apps choose to
do.  And when they delete stuff they get the ram back, which is nice
when things like maya can spit out verbose logs you have to parse to see
if something went wrong, or when you have to run some odd tool to
convert an entire file from one data format to another to parse out some
info, which results in an enormous file existing for only a second or
two.  Getting that ram back is very, very nice.  Tying up half the box's
ram with a block device when it's only briefly used is not.

> I think the ramfs limit code has a good argument from Alan for embedded
> devices, so that probably will make it in. However, even so it's obviously

I'd like to second that.  The oom killer is better than nothing, but
people are way more used to comprehending/diagnosing a full file system
rather than their apps crashing.  If I can tell it not to let the disk
grow big enough to hose the system, this is a Good Thing. :)

(We're selling this stuff to art majors.  They have an IT department,
but I strongly suspect they need all the help they can get.)

> not a 2.4.1 issue, AND as shown by the fact that apparently the thing is
> buggy and still worked on I wouldn't want the patches right now in the
> first place.

You mean other than the free when delete thing in .0?

Take your time.  Enjoy life.  Happy birthday.  Pet the cat.  Pack for
LWE.  Bask in the adoration of the world at large for surviving yet
another development cycle.  Teach your daughters to program (the world
needs more geekettes.  Where Illiad and Eric Raymond find them I'll
never know).

No rush.  I can grab an AC patch to get limits for testing and
configuring my config.  I'd just not sure I could convince management to
ship one, or our customers to accept it.  But that's my problem, isn't
it? :)

(Come to think of it, I could probably just use user-level filesystem
quotas in this case.  All the apps the node runs should be under one
user, and the log files root writes out are pretty much a rounding
error...  Hmmm...  Not exactly an elegant solution, and I can only hope
the multi-megabyte files that user owns on NFS don't throw off the
count.  (Queue pooh: Think think think, think-think...))

> Linus

Rob

P.S.  Linus responded to my email!  Wow!  Did it himself and
everything.  I feel like I've been initiated into something, but I don't
know what...

Learn from minix: fork ramfs.

[Rob Landley]

(Argh!  Linus replies to my post and my cc: to the linux-kernel was to
rutgers.edu.  Teach me to post on three hours of sleep, it's like
getting a hole-in-one with nobody around...)

Linus said in Re: Patch (repost): cramfs memory corruption fix

> I wonder what to do about this - the limits are obviously useful,
> as would the "use swap-space as a backing store" thing be. At the
> same time I'd really hate to lose the lean-mean-clean ramfs. 

So fork ramfs already.  Copy the snapshot you like as an educational
tool, call it skeletonfs.c or some such, and let the current code evolve
into something more useful.

Seems to me a dude named Andrew was in a similar situation a decade or
so back, and decided to resist all change in the name of having a clear
educational example.  Patch pressure built up past the "reimplementation
from scratch threshold event horizon thingy" (the tanenbaum-torvalds
barrier), at which point the code forked under its own weight anyway.

Saves a lot of bother to do it now, if you ask me.  You'll wind up with
a new ramfs one way or the other.  People will keep writing it as long
as it's not there.  (The whole "why climb mount everest" thing, you
know.)

I could, of course, be totally wrong about this...

Rob
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Anybody got 2.4.0 running on a 386 ?

[Tom Leete]

Robert Kaiser wrote:
> 
> Hi list,
> 
> I can't seem to get the new 2.4.0 kernel running on a 386 CPU.
> The kernel was built for a 386 Processor, Math emulation has been enabled.
> I tried three different 386 boards. Execution seems to get as far as
> pagetable_init() in arch/i386/mm/init.c, then it falls back into the BIOS as
> if someone had pressed the reset button. The same kernel boots fine on
> 486 and Pentium Systems.
  ^^^
> 
> Any ideas/suggestions ?
> 
> Rob
> 

This may be off the wall, but since the 386 is diskless the kernel was
obviously built elsewhere. Had that tree previously been used for a 486
build? You might decompile vmlinux and look for non-386 instructions at or
prior to the crash point.

It might be faster to recompile from 'make mrproper' and see if it works
then.

Tom
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Where did vm_operations_struct->unmap in 2.4.0 go?

[Keith Owens]

On Tue, 09 Jan 2001 19:27:24 -0800, 
Allen Unueco <[EMAIL PROTECTED]> wrote:
>Also where did get_module_symbol() and put_module_symbol() go?

http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg08791.html
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg11497.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.4.0: ieee1394: got invalid ack 3 from node 65473 (tcode 4)

[Wolfgang Spraul]

Incompatibility with "Sarotech FHD-352F/U Rev 1.0"

Using an external IDE drive in the Sarotech FireWire enclosure fails, even
though the Sarotech unit works with Win2K and other SBP2 drives work for me
(with Linux).

I'm using 2.4.0 together with sbp2_1394_122300.tar.gz.
ACK code 3 is not even mentioned in ieee1394.h.

I understand that the SBP2 driver is not (yet) included, but it will be shortly.
Also, I guess the same problem applies to raw1394.o together with the Sarotech
enclosure.
Wolfgang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[Security] LIDS 1.0.4 for 2.4.0 release.

[Huagang Xie]

Hi,

the new version ,

1. add inherit option when config file acls
2. add exec_domain from lids 0.9.11
3. add configuration support to multi-platform
4. bugfixed from 0.9.11

LIDS is a kernel patch and admin tools to enhance the current linux kernel
security.  

For more information, pls visit www.lids.org.

Thanks,
XIE

-- 
Happy Hacking

Linux Intrusion Detection System  
http://www.lids.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: storage over IP (was Re: [PLEASE-TESTME] Zerocopy networkingpatch, 2.4.0-1)

[David S. Miller]

   Date: Tue, 9 Jan 2001 19:18:53 -0800 (PST)
   From: dean gaudet <[EMAIL PROTECTED]>

   - NIC DMAs packet to memory
   - CPU reads headers from memory, figures out it's NFS
   - CPU copies data bytes from packet image in memory to pagecache

Yes, this is precisely what happens in the NFS client with
the zerocopy patches applied.

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]
Please read the FAQ at http://www.tux.org/lkml/

Where did vm_operations_struct->unmap in 2.4.0 go?

[Allen Unueco]

Sometime around test10 or test11 unmap left vm_operations_struct.  The
comment implies its there but it's gone.  Where did it go? 

How do I get a call back for a page unmap?

I ran into this while hacking the Nvidia kernel driver to work with
2.4.0.  I got the driver working but it's not 100%

Also where did get_module_symbol() and put_module_symbol() go?

-Allen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: storage over IP (was Re: [PLEASE-TESTME] Zerocopy networkingpatch, 2.4.0-1)

[dean gaudet]

On Tue, 9 Jan 2001, David S. Miller wrote:

>Date: Tue, 9 Jan 2001 18:56:33 -0800 (PST)
>From: dean gaudet <[EMAIL PROTECTED]>
>
>is NFS receive single copy today?
>
> With the zerocopy patches, NFS client receive is "single cpu copy" if
> that's what you mean.

yeah sorry, i meant:

- NIC DMAs packet to memory
- CPU reads headers from memory, figures out it's NFS
- CPU copies data bytes from packet image in memory to pagecache

-dean

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: storage over IP (was Re: [PLEASE-TESTME] Zerocopy networking patch,2.4.0-1)

[David S. Miller]

   Date: Tue, 9 Jan 2001 18:56:33 -0800 (PST)
   From: dean gaudet <[EMAIL PROTECTED]>

   is NFS receive single copy today?

With the zerocopy patches, NFS client receive is "single cpu copy" if
that's what you mean.

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]
Please read the FAQ at http://www.tux.org/lkml/

Re: storage over IP (was Re: [PLEASE-TESTME] Zerocopy networking patch,

[Alan Cox]

> fixed length headers).  i've never investigated the actual protocols
> though so maybe the solution used was to just push a lot of the detail
> down into the controllers.

The stuff I have access to (MPT fusion) pushes the FC handling down onto the
board. Basically you talk scsi and IP to it (See drivers/message/fusion in
-ac)

> 
> show that both use TCP/IP.  TCP/IP has variable length headers (or am i on
> crack?), which totally complicates the receive path.

TCP has variable length headers. It also prevents you re-ordering commands
in the stream which would be beneficial. I've not checked if the draft uses
multiple TCP streams but then you have scaling questions. 

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

storage over IP (was Re: [PLEASE-TESTME] Zerocopy networking patch,2.4.0-1)

[dean gaudet]

On Tue, 9 Jan 2001, Ingo Molnar wrote:

> On Mon, 8 Jan 2001, Rik van Riel wrote:
>
> > Having proper kiobuf support would make it possible to, for example,
> > do zerocopy network->disk data transfers and lots of other things.
>
> i used to think that this is useful, but these days it isnt.

this seems to be in the general theme of "network receive is boring".
which i mostly agree with... except recently i've been thinking about an
application where it may not be so boring, but i haven't researched all
the details yet.

the application is storage over IP -- SAN using IP (i.e. gigabit ethernet)
technologies instead of fiberchannel technologies.  several companies are
doing it or planning to do it (for example EMC, 3ware).

i'm taking a wild guess that SCSI over FC is arranged conveniently to
allow a scatter request to read packets off the FC NIC such that the
headers go one way and the data lands neatly into the page cache (i.e.
fixed length headers).  i've never investigated the actual protocols
though so maybe the solution used was to just push a lot of the detail
down into the controllers.

a quick look at the iSCSI specification
, and the
FCIP spec

show that both use TCP/IP.  TCP/IP has variable length headers (or am i on
crack?), which totally complicates the receive path.

the iSCSI requirements document seems to imply they're happy with pushing
this extra processing down to a special storage NIC.  that kind of sucks
-- one of the benefits of storage over IP would be the ability to
redundantly connect a box to storage and IP with only two NICs (instead of
4 -- 2 IP and 2 FC).

is NFS receive single copy today?

anyone tried doing packet demultiplexing by grabbing headers on one pass
and scattering the data on a second pass?

i'm hoping i'm missing something.  anyone else looked around at this stuff
yet?

-dean

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] major security bug in reiserfs (may affect SuSE Linux)

[Chris Mason]

On Wednesday, January 10, 2001 02:32:09 AM +0100 Marc Lehmann <[EMAIL PROTECTED]> wrote:
>>> EIP; c013f911<=
> Trace; c013f706 
> Trace; c0136e01 
> 

Here is a patch against our 2.4 code (3.6.25) that does the
same as the patch posted for 3.5.29:

-chris

--- linux/include/linux/reiserfs_fs.h.1 Tue Jan  9 21:22:27 2001
+++ linux/include/linux/reiserfs_fs.h   Tue Jan  9 21:22:55 2001
@@ -926,8 +926,7 @@
 //((block_size - BLKH_SIZE - IH_SIZE - DEH_SIZE * 2) / 2)
 
 // two entries per block (at least)
-#define REISERFS_MAX_NAME_LEN(block_size) \
-((block_size - BLKH_SIZE - IH_SIZE - DEH_SIZE))
+#define REISERFS_MAX_NAME_LEN(block_size) 255
 
 
 
--- linux/fs/reiserfs/dir.c.1   Tue Jan  9 21:22:19 2001
+++ linux/fs/reiserfs/dir.c Tue Jan  9 21:21:02 2001
@@ -142,6 +142,10 @@
if (!d_name[d_reclen - 1])
d_reclen = strlen (d_name);

+   if (d_reclen > REISERFS_MAX_NAME_LEN(inode->i_sb->s_blocksize)){
+   /* too big to send back to VFS */
+   continue ;
+   }
d_off = deh_offset (deh);
filp->f_pos = d_off ;
d_ino = deh_objectid (deh);


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.19pre7

[Peter Samuelson]

[Mike van Smoorenburg]
> Also calling kwhich with multiple arguments was actually the idea
> behind the script.

Yes, and that's why my optimization patch (in 2.2.19pre3, since
reverted) broke -- it relied on multiple arguments.

Alan, could you put it back in now?

Peter

--- 2.2.19-7/Makefile~  Tue Jan  9 20:20:14 2001
+++ 2.2.19-7/Makefile   Tue Jan  9 20:27:27 2001
@@ -24,12 +24,14 @@
 LD =$(CROSS_COMPILE)ld
 #
 #  foo-bar-gcc for cross builds
-#  gcc272 for Debian's old compiler for kernels
 #  kgcc for Conectiva, Mandrake and Red Hat 7
+#  gcc272 for Debian
 #  otherwise 'cc'
 #
-CC =$(shell if [ -n "$(CROSS_COMPILE)" ]; then echo $(CROSS_COMPILE)gcc; else \
-   $(CONFIG_SHELL) scripts/kwhich gcc272 2>/dev/null || $(CONFIG_SHELL) 
scripts/kwhich kgcc 2>/dev/null || echo cc; fi) \
+CCFOUND :=$(shell $(CONFIG_SHELL) scripts/kwhich kgcc gcc272 cc gcc)
+## Better, but requires GNU make 3.78
+##CC   =$(if $(CROSS_COMPILE),$(CROSS_COMPILE)gcc,$(CCFOUND)) -D__KERNEL__ -I$(HPATH)
+CC =$(shell if [ -n "$(CROSS_COMPILE)" ]; then echo $(CROSS_COMPILE)gcc; else 
+echo $(CCFOUND); fi) \
-D__KERNEL__ -I$(HPATH)
 CPP=$(CC) -E
 AR =$(CROSS_COMPILE)ar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Subtle MM bug

[Andrea Arcangeli]

On Wed, Jan 10, 2001 at 01:45:47AM +, David Woodhouse wrote:
> How does this affect embedded systems with no swap space at all?

If there's no swap the swap-cache dirty-sticky issue can't arise.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] major security bug in reiserfs (may affect SuSE Linux)

[Chris Mason]

On Wednesday, January 10, 2001 02:32:09 AM +0100 Marc Lehmann <[EMAIL PROTECTED]> wrote:

>>> EIP; c013f911<=
> Trace; c013f706 
> Trace; c0136e01 

The buffer reiserfs is sending to filldir is big enough for
the huge file name, so I think the real fix should be done in VFSland.

But, in the interest of providing a quick, obviously correct fix, this
reiserfs only patch will refuse to create file names larger 
than 255 chars, and skip over any directory entries larger than 
255 chars.

--- linux/include/linux/reiserfs_fs.h.1 Tue Jan  9 21:56:18 2001
+++ linux/include/linux/reiserfs_fs.h   Tue Jan  9 21:56:33 2001
@@ -467,7 +467,7 @@
 /* name by bh, ih and entry_num */
 #define B_I_E_NAME(entry_num,bh,ih) ((char *)(bh->b_data + ih->ih_item_location + 
(B_I_DEH(bh,ih)+(entry_num))->deh_location))
 
-#define REISERFS_MAX_NAME_LEN(block_size) (block_size - BLKH_SIZE - IH_SIZE - 
DEH_SIZE)/* -SD_SIZE when entry will contain stat data */
+#define REISERFS_MAX_NAME_LEN(block_size) 255
 
 /* this structure is used for operations on directory entries. It is not a disk 
structure. */
 /* When reiserfs_find_entry or search_by_entry_key find directory entry, they return 
filled reiserfs_dir_entry structure */
--- linux/fs/reiserfs/dir.c.1   Tue Jan  9 22:06:06 2001
+++ linux/fs/reiserfs/dir.c Tue Jan  9 22:15:17 2001
@@ -159,6 +159,10 @@
d_name = B_I_DEH_ENTRY_FILE_NAME (bh, ih, deh);
d_off = deh->deh_offset;
d_ino = deh->deh_objectid;
+   if (d_reclen > REISERFS_MAX_NAME_LEN(inode->i_sb->s_blocksize)){
+   /* it is too big to send back to VFS */
+   continue ;
+   }
if (d_reclen <= 32) {
local_buf = small_buf ;
} else {

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] More compile warning fixes for 2.4.0

[Andrea Arcangeli]

On Tue, Jan 09, 2001 at 01:31:35PM -0800, Linus Torvalds wrote:
> don't have to worry about undocumented extensions etc.

Infact I don't blame gcc maintainers for that, but the standard. Ok, minor
issue.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1

[Dave Zarzycki]

On Tue, 9 Jan 2001, David S. Miller wrote:

> Ignore Ingo's comments about the MSG_NOCOPY flag, I've not included
> those parts in the zerocopy patches as they are very controversial
> and require some VM layer support.

Okay, I talked to some kernel engineers where I work and they were (I
think) very justifiably skeptical of zero-copy work with respect to
read/write style APIs.

> Basically, it pins the userspace pages, so if you write to them before
> the data is fully sent and the networking buffer freed, they get
> copied with a COW fault.

Yum... Assuming a gigabit ethernet link is saturated with the
sendmsg(MSG_NOCOPY) API, what is CPU utilization like for a given clock
speed and processor make? It is any different than the sendfile() case?

davez

-- 
Dave Zarzycki
http://thor.sbay.org/~dave/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] More compile warning fixes for 2.4.0

[Rich Baum]

On 9 Jan 2001, at 10:51, Linus Torvalds wrote:

> 
> 
> On Tue, 9 Jan 2001, Albert D. Cahalan wrote:
> 
> > [about labels w/o statements after them]
> > 
> > >> Is this really a kernel bug? This is common idiom in C, so 
gcc
> > >> shouldn't warn about it. If it does, it is a bug in gcc IMHO.
> > >
> > > No, it is not a common idiom in C.  It has _never_ been valid 
C.
> > >
> > > GCC originally allowed it due to a mistake in the grammar; 
we
> > > now warn for it.  Fix your source.
> > 
> > Since neither -ansi nor -std=foo was specified, gcc should just
> > shut up and be happy. Consider this as another GNU 
extension.
> 
> No, it was a gcc bug that gcc accepted the syntax in the first 
place.
> 
> Let the gcc people fix the bugs they find without complaining 
about them.
> After all, gcc would have been perfectly correct in signalling this 
as a
> syntax error, and aborted compilation. The fact that gcc only 
warns about
> it is a sign of grace - it's not as if it is a _useful_ extension that
> gives the programmer anything new and should be left in for that 
reason.
> 
> We'll fix up the kernel. That's where the bug is.
> 
>   Linus
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-
kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

Here's a patch that takes care of all warnings of this type I have 
found in 2.4.0. If anyone else finds more of these warnings let me 
know or look at me patch to see how to do it yourself.
 

diff -urN -X dontdiff linux/drivers/block/cpqarray.c rb/drivers/block/cpqarray.c
--- linux/drivers/block/cpqarray.c  Thu Nov 16 14:30:29 2000
+++ rb/drivers/block/cpqarray.c Tue Jan  9 18:13:59 2001
@@ -1321,7 +1321,7 @@
case IDA_WRITE_MEDIA:
kfree(p);
break;
-   default:
+   default:;
/* Nothing to do */
}
 
diff -urN -X dontdiff linux/drivers/cdrom/cm206.c rb/drivers/cdrom/cm206.c
--- linux/drivers/cdrom/cm206.c Fri Oct 27 01:35:47 2000
+++ rb/drivers/cdrom/cm206.cFri Jan  5 20:36:20 2001
@@ -1283,7 +1283,7 @@
   case 1: 
 kfree(cd);
 release_region(cm206_base, 16);
-  default:
+  default:;
   }
 }
 
diff -urN -X dontdiff linux/drivers/cdrom/mcd.c rb/drivers/cdrom/mcd.c
--- linux/drivers/cdrom/mcd.c   Fri Oct 27 01:35:47 2000
+++ rb/drivers/cdrom/mcd.c  Fri Jan  5 20:36:42 2001
@@ -1158,7 +1158,7 @@
   return;
 }
 blk_cleanup_queue(BLK_DEFAULT_QUEUE(MAJOR_NR));
-  default:
+  default:;
   }
 }
 
diff -urN -X dontdiff linux/drivers/char/ftape/lowlevel/fdc-isr.c 
rb/drivers/char/ftape/lowlevel/fdc-isr.c
--- linux/drivers/char/ftape/lowlevel/fdc-isr.c Mon Oct 16 14:58:51 2000
+++ rb/drivers/char/ftape/lowlevel/fdc-isr.cFri Jan  5 20:43:04 2001
@@ -81,7 +81,7 @@
case overrun_error:
TRACE(ft_t_noise, "overrun error");
break;
-   default:
+   default:;
}
TRACE_EXIT;
 }
@@ -184,7 +184,7 @@
case no_data_error:
ft_history.no_data_errors++;
break;
-   default:
+   default:;
}
 }
 
diff -urN -X dontdiff linux/drivers/ieee1394/pcilynx.c rb/drivers/ieee1394/pcilynx.c
--- linux/drivers/ieee1394/pcilynx.cWed Nov 29 00:45:16 2000
+++ rb/drivers/ieee1394/pcilynx.c   Fri Jan  5 20:15:30 2001
@@ -1485,7 +1485,7 @@
 pci_free_consistent(lynx->dev, LOCALRAM_SIZE, lynx->pcl_mem,
 lynx->pcl_mem_dma);
 #endif
-case clear:
+case clear:;
 /* do nothing - already freed */
 }
 
diff -urN -X dontdiff linux/drivers/isdn/eicon/eicon_idi.c 
rb/drivers/isdn/eicon/eicon_idi.c
--- linux/drivers/isdn/eicon/eicon_idi.cSun Aug 13 12:05:32 2000
+++ rb/drivers/isdn/eicon/eicon_idi.c   Fri Jan  5 20:15:08 2001
@@ -2506,7 +2506,7 @@
case ISDN_PROTO_L2_TRANS:
idi_do_req(ccard, chan, 
N_CONNECT, 1);
break;
-   default:
+   default:;
/* On most incoming calls we 
use automatic connect */
/* idi_do_req(ccard, chan, 
N_CONNECT, 1); */
}
diff -urN -X dontdiff linux/drivers/isdn/eicon/eicon_pci.c 
rb/drivers/isdn/eicon/eicon_pci.c
--- linux/drivers/isdn/eicon/eicon_pci.cSun Aug 13 12:05:32 2000
+++ rb/drivers/isdn/eicon/eicon_pci.c   Fri Jan  5 20:14:49 2001
@@ -86,7 +86,7 @@
printk(KERN_INFO "%s: DriverID='%s' CardID=%d\n",
eicon_ctype_name[ctype], did, card_id);
}
-err:
+err:;
}

Re: Anybody got 2.4.0 running on a 386 ?

[Miles Lane]

Hi Rob,

Just out of curiosity, did you use a 2.2 series
.config file and then run make oldconfig or did
you build a new .config file from scratch?

I have periodically built kernels that crashed
immediately at the point you mention.  Usually this
was due to me choose configuration options that
were incompatible with my machine's hardware.

Another time, the machine wouldn't boot because
I needed a new version of LILO.  I also have seen
at least one machine where I needed to specify
"linear" as one of the options in lilo.conf.
If you aren't specifying "linear" now, give it
a try.

IIRC, here's my litany of goofed configurations:

Building support for multiple framebuffer
devices.  Apparently, the kernel would
hang in the chip detection process.

Wrong CPU architecture.

Wrong IDE chipset specified.

Built EXT2 as a module, but / was on
an EXT2 partition.

I may have hit some other bogus configurations
over the last two years, but these are ones that
come to mind.

Miles

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

IBM Netfinity with 2.4.0

[Stéphane Borel]

We have two Netfinity (7100 with 4 Xeon and 4500R with two PIII) and we
have noticed a weird behaviour with kernel 2.4.0 test and final.

*On the 7100, the final kernel can't detect two pci card (3C980 and
ForeRunnerLE.
*On the 4500R, the test kernel crash unexpectedly in two or three hours

And we have had two hard drive crashes with the serveraid cards that
resulted in a unusable filesystem.

Does anyone know if these are known issues of 2.4 kernels or if it may
be caused by another problem ?

The systems work with 2.2 kernels but we would like to use 2.4 for atm
support.

Thank you for your help.

-- 
Stef
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Subtle MM bug

[David Woodhouse]

On Tue, 9 Jan 2001, Linus Torvalds wrote:

> And this _is_ a downside, there's no question about it. There's the worry
> about the potential loss of locality, but there's also the fact that you
> effectively need a bigger swap partition with 2.4.x - never mind that
> large portions of the allocations may never be used. You still need the
> disk space for good VM behaviour.
>
> There are always trade-offs, I think the 2.4.x tradeoff is a good one.

How does this affect embedded systems with no swap space at all?

-- 
dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] hashed device lookup (Does NOT meet Linus' sumission

[Ben Greear]

"Christopher E. Brown" wrote:
> 

> Think VLANing switch clusters.  Say 4 switches connected by
> GigE on 4 floors or in 4 separate building.  Now, across these
> switches 20 VLANS are running, with the switches enforcing VLAN
> partitioning.  The client PCs know nothing about it, as each one
> resides within a single VLAN.

That would seem to cut down broadcast packets, and generally be a good
thing!

> 
> Now we have our Linux box with 2 x 100Mbit FD links to the
> switch cluster running 10 VLANS per interface, and an external
> DS1/SDSL/whatever connection.  We now have 20 separate zones with
> different security controls per zone, with per switchport control over
> who resided in what group.  Or even forget the routing and just
> plugging a Linux box to a companies 200VLAN setup to provide
> DHCP/whatever.
> 
> I must say, I *hate* VLANs for this use, it is a horrible
> thing to do that wastes massive amounts of bandwidth on simulating a
> local broadcast domain across a much larger area, but oh well.  As
> long as we have stupid managers and brain dead sales persons not much
> will change.  Are there better things to do than VLAN?  YES!  Will we
> get stuck with needing VLANs in the real world?  YES!

Umm, how does using VLANs lead to wasting massive amount of bandwidth?
(You seem to be saying that by partitioning the network we make each
partition bigger??)

What are the better solutions?

And what does your dislike for sales and management have to do with
the topic at hand?



-- 
Ben Greear ([EMAIL PROTECTED])  http://www.candelatech.com
Author of ScryMUD:  scry.wanfear.com (Released under GPL)
http://scry.wanfear.com   http://scry.wanfear.com/~greear
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: SCSI scanner problem with all kernels since 2.3.42

[Tim Waugh]

On Tue, Jan 09, 2001 at 03:53:02PM -0500, Douglas Gilbert wrote:

> by timeouts ** resulting in scsi bus resets. Anyway the problem
> seems to disappear with the recently released SANE 1.0.4 .
> [The original report was based on SANE 1.0.3 and earlier.]

In fact my report that the problem went away was wrong. :-(

> ** SANE's newer sg interface shortens the per command timeout
> from 10 minutes to 10 seconds. Most other OSes interfaces in
> SANE have a timeout value of 1 minute or more. I suspect 10 
> seconds may be too short.

Increasing the timeout fixed the problem.

Thanks,
Tim.
*/

 PGP signature

Re: [PATCH] n_r3964: restore_flags on failure

[David Woodhouse]

On Tue, 9 Jan 2001, Arnaldo Carvalho de Melo wrote:

> --- linux-2.4.0-ac4/drivers/char/n_r3964.cTue Dec 19 11:25:34 2000
> +++ linux-2.4.0-ac4.acme/drivers/char/n_r3964.c   Tue Jan  9 14:23:07 2001

> +  restore_flags(flags);

/me scratches head...

Err is there any reason to believe that the locking therein actually
works at all?

-- 
dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Andrea Arcangeli]

On Wed, Jan 10, 2001 at 02:17:35AM +0100, Ingo Molnar wrote:
> i understand now - well, there is no reliable RAID1/RAID5 support in the
> stock 2.2 kernel indeed, you need the 0.90 patch.

I used raid1 without problems in stock 2.2 kernel. For raid5 I certainly
agree ;).

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Updated zerocopy patch up on kernel.org

[David S. Miller]

   Date: Tue, 09 Jan 2001 20:23:17 -0500
   From: Jeff Garzik <[EMAIL PROTECTED]>

   Is there any value to supporting fragments in a driver which
   doesn't do hardware checksumming?  IIRC Alexey had a patch to do
   such for Tulip, but I don't see it in the above patchset.

I'm actually considering making the SG w/o hwcsum situation illegal.

Basically, with SG only, you can run into some problems.
We don't prevent anyone from making modifications to the
paged data, we just grab references to the pages.

This works perfectly fine when the card does the checksumming,
the card DMAs a snapshot of the data into it's internal buffers,
checksums that local snapshot of the data, and the checksum is fine.

If, on the other hand, we're doing this in software, we can send out
packets with bad checksums.  The next retransmit could fix it up, but
this is a horrible scheme quality of implementation wise.

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]
Please read the FAQ at http://www.tux.org/lkml/

(no subject)

[Eko Sulistiono]

 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1

[David S. Miller]

   Date:Tue, 9 Jan 2001 17:14:33 -0800 (PST)
   From: Dave Zarzycki <[EMAIL PROTECTED]>

   On Tue, 9 Jan 2001, Ingo Molnar wrote:

   > then you'll love the zerocopy patch :-) Just use sendfile() or specify
   > MSG_NOCOPY to sendmsg(), and you'll see effective memory-to-card
   > DMA-and-checksumming on cards that support it.

   I'm confused.

   In user space, how do you know when its safe to reuse the buffer that was
   handed to sendmsg() with the MSG_NOCOPY flag? Or does sendmsg() with that
   flag block until the buffer isn't needed by the kernel any more? If it
   does block, doesn't that defeat the use of non-blocking I/O?

Ignore Ingo's comments about the MSG_NOCOPY flag, I've not included
those parts in the zerocopy patches as they are very controversial
and require some VM layer support.

Basically, it pins the userspace pages, so if you write to them before
the data is fully sent and the networking buffer freed, they get
copied with a COW fault.

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]
Please read the FAQ at http://www.tux.org/lkml/

Re: Updated zerocopy patch up on kernel.org

[Jeff Garzik]

"David S. Miller" wrote:
> 
> Nothing interesting or new, just merges up with the latest 2.4.1-pre1
> patch from Linus.
> 
> ftp.kernel.org:/pub/linux/kernel/people/davem/zerocopy-2.4.1p1-1.diff.gz
> 
> I haven't had any reports from anyone, which must mean that it is
> working perfectly fine and adds no new bugs, testers are thus in
> nirvana and thus have nothing to report.  :-)

Is there any value to supporting fragments in a driver which doesn't do
hardware checksumming?  IIRC Alexey had a patch to do such for Tulip,
but I don't see it in the above patchset.

Jeff


-- 
Jeff Garzik   | "You see, in this world there's two kinds of
Building 1024 |  people, my friend: Those with loaded guns
MandrakeSoft  |  and those who dig. You dig."  --Blondie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1

[Ingo Molnar]

On Tue, 9 Jan 2001, Dave Zarzycki wrote:

> In user space, how do you know when its safe to reuse the buffer that
> was handed to sendmsg() with the MSG_NOCOPY flag? Or does sendmsg()
> with that flag block until the buffer isn't needed by the kernel any
> more? If it does block, doesn't that defeat the use of non-blocking
> I/O?

sendmsg() marks those pages COW and copies the original page into a new
one for further usage. (the old page is used until the packet is
released.) So for maximum performance user-space should not reuse such
buffers immediately.

Ingo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [Announcement] linux-kernel v2.0.39

[Keith Owens]

On Wed, 10 Jan 2001 10:27:44 +1100, 
Eyal Lebedinsky <[EMAIL PROTECTED]> wrote:
>My 'make dep' fails in the following way. This is on Debian 2.2, I
>commented
>if [ -n "amigamouse.c atarimouse.c atixlmouse.c baycom.c busmouse.c
>cd1865.h conmakehash.c console.c console_struct.h consolemap.c
>consolemap.h cyclades.c defkeymap.c diacr.h digi.h digi_bios.h
>digi_fep.h fbmem.c fep.h h8.c h8.h isicom.c istallion.c kbd_kern.h
>keyb_m68k.c keyboard.c lp.c lp_intern.c lp_m68k.c mem.c misc.c
>msbusmouse.c n_tty.c pcwd.c pcxx.c pcxx.h psaux.c pty.c random.c
>riscom8.c riscom8.h riscom8_reg.h rtc.c scc.c selection.c selection.h
>serial.c softdog.c specialix.c specialix_io8.h stallion.c tga.c
>tpqic02.c tty_io.c tty_ioctl.c vc_screen.c vesa_blank.c vga.c vt.c
>vt_kern.h wd501p.h wdt.c" ]; then \
>/usr/local/src/linux/scripts/mkdep *.[chS] > .depend; fi
>make[2]: *** [fastdep] Error 135

135 == 128+7 => E2BIG (Arg list too long).  What does
  ls -l /usr/local/src/linux/drivers/char/*.[chS] | wc
report?  And which kernel/libc are you compiling on?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Ingo Molnar]

On Wed, 10 Jan 2001, Andrea Arcangeli wrote:

> > [ the only category impacted are people who are still using the
> > RAID1/RAID4,5 code in the stock 2.2 kernel - i do believe the number of
>   
> That's the category Hubert was talking about indeed.

i understand now - well, there is no reliable RAID1/RAID5 support in the
stock 2.2 kernel indeed, you need the 0.90 patch.

Ingo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1

[Dave Zarzycki]

On Tue, 9 Jan 2001, Ingo Molnar wrote:

> then you'll love the zerocopy patch :-) Just use sendfile() or specify
> MSG_NOCOPY to sendmsg(), and you'll see effective memory-to-card
> DMA-and-checksumming on cards that support it.

I'm confused.

In user space, how do you know when its safe to reuse the buffer that was
handed to sendmsg() with the MSG_NOCOPY flag? Or does sendmsg() with that
flag block until the buffer isn't needed by the kernel any more? If it
does block, doesn't that defeat the use of non-blocking I/O?

davez

-- 
Dave Zarzycki
http://thor.sbay.org/~dave/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Updated zerocopy patch up on kernel.org

[David S. Miller]

Nothing interesting or new, just merges up with the latest 2.4.1-pre1
patch from Linus.

ftp.kernel.org:/pub/linux/kernel/people/davem/zerocopy-2.4.1p1-1.diff.gz

I haven't had any reports from anyone, which must mean that it is
working perfectly fine and adds no new bugs, testers are thus in
nirvana and thus have nothing to report.  :-)

As much as I would like to believe this, I know that there must be
some (however minor) bug in there.  So please make the effort to
report bugs if you do spot them.  Again, a reminder to test bugs also
against vanilla 2.4.1pre1 and report the bug against that if the bug
appears there too. This way, I know what bugs are specific to the
zerocopy stuff and which are not.

Thanks.

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]
Please read the FAQ at http://www.tux.org/lkml/

megaraid.c is broken

[Venkatesh Ramamurthy]

Hi,
I am the linux developer for this card. This is the problem we have fixed
long back and the version of linux driver that comes with 2.4.0 is way too
old. A new driver will be released in a weeks time. 
Thanks
Venkat
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Andrea Arcangeli]

> On Tue, 9 Jan 2001, Hubert Mantel wrote:
> > Right, but now there is a problem: Software RAID. The RAID code of
> > 2.4.0 is not backwards compatible to the one in 2.2.18; if somebody
> > has used 2.4.0 on softraid and discovers some problem, he can not
> > switch back to some official 2.2 kernel. [...]
   

On Wed, Jan 10, 2001 at 01:33:10AM +0100, Ingo Molnar wrote:
> [ the only category impacted are people who are still using the
> RAID1/RAID4,5 code in the stock 2.2 kernel - i do believe the number of


That's the category Hubert was talking about indeed.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] major security bug in reiserfs (may affect SuSE Linux)

[Vladimir V. Saveliev]

Hi

Marc Lehmann wrote:

> We are still investigating, but there seems to be a major security problem
> in at least some versions of reiserfs. Since reiserfs is shipped with
> newer versions of SuSE Linux and the problem is too easy to reproduce and
> VERY dangerous I think alerting people to this problem is in order.
>
> We have tested and verified this problem on a number of different systems
> and kernels 2.2.17/2.2.8 with reiserfs-3.5.28 and probably other versions.
>
> Basically, you do:
>
> mkdir "$(perl -e 'print "x" x 768')"
>
> I.e. create a very long directory. The name doesn't seem to be of
> relevance (we found this out by doing mkdir "$(cat /etc/hosts)" for other
> tests). This works.  The next ls (or echo *) command will segfault and the
> kernel oopses. all following accesses to the volume in question will oops
> and hang the process, even afetr a reboot.
>

Hmm,
mkdir "$(perl -e 'print "x" x 768')"
ls
echo *

works here as it should. (2.2.18 and reiserfs-3.5.29)

Did I miss something?

Thanks,
vs



>
> reiserfsck (the filesystem check program) does _NOT_ detect or solve this
> problem:
>
> Replaying journal..ok
> Checking S+tree..ok
> Comparing bitmaps..ok
>
> But fortunately, rmdir  works and seems to leave the filesystem
> undamaged.
>
> Since a kernel oops results (see below), this indicates a buffer overrun
> (the kernel jumps to address 78787878, which is "") inside the kernel,
> which is of course very nasty (think ftp-upload!) and certainly gives you
> root access from anywhere, even from inside a chrooted environment. We
> didn't pursue this further.
>
> The best workaround at this time seems to be to uninstall reiserfs
> completely or not allow any user access (even indirect) to these volumes.
> While this individual bug might be easy to fix, we believe that other,
> similar bugs should be easy to find so reiserfs should not be trusted (it
> shouldn't be trusted to full user access for other reasons anyway, but it
> is still widely used).
>
> Unable to handle kernel paging request at virtual address 78787878
> current->tss.cr3 = 0d074000, %cr3 = 0d074000
> *pde = 
> Oops: 0002
> CPU:0
> EIP:0010:[]
> EFLAGS: 00010282
> eax:    ebx: bfffe78c   ecx:    edx: bfffe78c
> esi: ccbddd62   edi: 78787878   ebp: 0300   esp: ccbddd3c
> ds: 0018   es: 0018   ss: 0018
> Process bash (pid: 292, process nr: 54, stackpage=ccbdd000)
> Stack: c013f66a ccbddf6c cd10 ccbddd62 030c c0136d49 0700 2013
>1000 7878030c 78787878 78787878 78787878 78787878 78787878 78787878
>78787878 78787878 78787878 78787878 78787878 78787878 78787878 78787878
> Call Trace: [] []
> Code: 89 1f 8b 44 24 18 29 47 08 31 c0 5b 5e 5f 5d 81 c4 2c 01 00
>
> --
>   -==- |
>   ==-- _   |
>   ---==---(_)__  __   __   Marc Lehmann  +--
>   --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
>   -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
> The choice of a GNU generation   |
>  |

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

SIGSEGV: Linux 2.4.0 and Konqueror 1.9.8 (from KDE 2.1 Beta 1)

[Roger Larsson]

Hi,

Konqueror behaves really strange with the new kernel (compiled with 2.95.2 as 
all my kernels for a very long time)

I have not seen this behaviour (to this extent) with earlier 2.4 kernels.

Included a strace... strange use of brk - or? [included /proc/pid/maps too]
It bugs out like this for other reasons as well. (not zdnet specific)

Note: read on it is not the icon stuff that is strange...

Computer: PPro 180, 96MB RAM
Swap [from dmesg] :
 Adding Swap: 530136k swap-space (priority -1)
 Adding Swap: 133048k swap-space (priority -2)
 
Linux version 2.4.0 (root@dox) (gcc version 2.95.2 19991024 (release)) #2 Fri 
Jan 5 23:49:17 CET 2001

access("/opt/kde2/share/apps/konqueror/icons/hicolor/22x22/actions/favicons/www.zdnet.com.xpm",
 
R_OK) = -1 ENOENT (No such file or directory)
access("/opt/kde2/share/icons/hicolor/22x22/actions/favicons/www.zdnet.com.xpm", 
R_OK) = -1 ENOENT (No such file or directory)
[...]
R_OK) = -1 ENOENT (No such file or directory)
access("/opt/kde2/share/icons/locolor/22x22/actions/favicons/www.zdnet.com.xpm", 
R_OK) = -1 ENOENT (No such file or directory)
time([979085700])   = 979085700
gettimeofday({979085700, 853318}, NULL) = 0
write(7, "\2\1\2\0.\1\0\0\1\0\0\0", 12) = 12
write(7, "\0\0\0\17konqueror-3415\0\0\0\0\vkonqueror"..., 111) = 111
write(7, "\0\0\0\210\0h\0t\0t\0p\0:\0/\0/\0w\0w\0w\0.\0z\0d\0n"..., 191) = 191
gettimeofday({979085700, 857154}, NULL) = 0
gettimeofday({979085700, 857408}, NULL) = 0
gettimeofday({979085700, 858925}, NULL) = 0
write(13, "ae_50_\0\0\0\3\0\0\0\20\0r\0e\0f\0e\0r\0r\0e"..., 184) = 184
write(13, "   105_43_\0\0\0\10\0h\0t\0t\0p\377\377\377\377\377\377"..., 271) 
= 271
gettimeofday({979085700, 863577}, NULL) = 0
gettimeofday({979085700, 863811}, NULL) = 0
gettimeofday({979085700, 864752}, NULL) = 0
gettimeofday({979085700, 865038}, NULL) = 0
gettimeofday({979085700, 865229}, NULL) = 0
gettimeofday({979085700, 865774}, NULL) = 0
gettimeofday({979085700, 866013}, NULL) = 0
gettimeofday({979085700, 866320}, NULL) = 0
gettimeofday({979085700, 866512}, NULL) = 0
gettimeofday({979085700, 866799}, NULL) = 0
gettimeofday({979085700, 870601}, NULL) = 0
write(3, "F\20\5\0\3\6\0\4\v\2\0\4\0\0\0\0Q\2\20\0J\5\n\0\3\6\0\4"..., 2048) 
= 2048
write(3, "B\20\5\0\2\2\0\4\v\2\0\4\1\0\2\0\1\0\23\0@\0\4\0\2\2\0"..., 500) = 
500ioctl(3, FIONREAD, [256])   = 0
read(3, "\26\0$L\f\2\0\4\f\2\0\4\0\0\0\0\3\0\3\0Q\2\20\0\0\0\0\0"..., 256) = 
256ioctl(3, FIONREAD, [0]) = 0
ioctl(3, FIONREAD, [0]) = 0
ioctl(3, FIONREAD, [0]) = 0
write(3, "=\0\4\0\f\2\0\4\0\0\0\0=\2\20\0005\20\4\0\t\6\0\4&\0\0"..., 268) = 
268write(3, ";\3\5\0\7\2\0\4\0\0\0\0\3\0\3\0\24\0\20\0;\3\5\0\10\2\0"..., 
676) = 676
ioctl(3, FIONREAD, [0]) = 0
ioctl(3, FIONREAD, [0]) = 0
gettimeofday({979085700, 876529}, NULL) = 0
select(16, [3 4 6 7 9 10 12 13 14 15], NULL, NULL, {0, 0}) = 2 (in [7 13], 
left {0, 0})
read(13, " 4_ a_", 10)  = 10
read(13, "\0\0\0\0", 4) = 4
read(7, "\2\1\0\2.\1\0\0", 8)   = 8
read(7, "\1\0\0\0", 4)  = 4
read(7, "\0\0\0\17konqueror-3415\0\0\0\0\vkonqueror"..., 302) = 302
brk(0x84f8000)  = 0x84f8000
brk(0x84fd000)  = 0x84fd000
brk(0x8502000)  = 0x8502000
brk(0x8507000)  = 0x8507000
brk(0x850c000)  = 0x850c000
brk(0x8511000)  = 0x8511000
brk(0x8516000)  = 0x8516000
brk(0x851b000)  = 0x851b000
brk(0x852)  = 0x852
[...]
brk(0xd02d000)  = 0xd02d000
brk(0xd02f000)  = 0xd02f000
brk(0xd031000)  = 0xd02f000
brk(0xd031000)  = 0xd02f000
brk(0xd031000)  = 0xd02f000
brk(0xd031000)  = 0xd02f000
brk(0xd031000)  = 0xd02f000
brk(0xd031000)  = 0xd02f000
--- SIGSEGV (Segmentation fault) ---
--- SIGSEGV (Segmentation fault) ---
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++  

roger@dox:~ > cat /proc/3507/maps
08048000-0804d000 r-xp  03:45 512886 /opt/kde2/bin/kdeinit
0804d000-0804f000 rw-p 4000 03:45 512886 /opt/kde2/bin/kdeinit
0804f000-0848c000 rwxp  00:00 0
4000-40013000 r-xp  16:04 73442  /lib/ld-2.1.3.so
40013000-40014000 rw-p 00012000 16:04 73442  /lib/ld-2.1.3.so
40014000-40015000 rw-p  00:00 0
40015000-40035000 r-xp  03:45 1121794
/opt/kde2/lib/libDCOP.so.1.0.0 40035000-40037000 rw-p 0001f000 03:45 1121794  
  /opt/kde2/lib/libDCOP.so.1.0.0 40037000-40063000 r-xp  03:45 
1121834/opt/kde2/lib/libkparts.so.1.0.0
40063000-40065000 rw-p 0002b000 03:45 1121834

[PATCH] Fix raid5 on sparc

[Anton Blanchard]

Hi,

On sparc the length of an xor block must be a multiple of 128 bytes.
Bad things happen otherwise.

Anton

Index: xor.c
===
RCS file: /cvs/linux/drivers/md/xor.c,v
retrieving revision 1.3
diff -u -r1.3 xor.c
--- xor.c   2000/12/06 13:30:36 1.3
+++ xor.c   2001/01/10 00:43:02
@@ -58,7 +58,11 @@
 static struct xor_block_template *template_list;
 
 /* The -6*32 shift factor colors the cache.  */
+#ifdef __sparc__
+#define BENCH_SIZE (PAGE_SIZE)
+#else
 #define BENCH_SIZE (PAGE_SIZE-6*32)
+#endif
 
 static void
 do_xor_speed(struct xor_block_template *tmpl, void *b1, void *b2)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] major security bug in reiserfs (may affect SuSELinux)

[Chris Mason]

On Wednesday, January 10, 2001 12:42:01 AM +0100 Marc Lehmann
<[EMAIL PROTECTED]> wrote:

> We are still investigating, but there seems to be a major security problem
> in at least some versions of reiserfs. Since reiserfs is shipped with
> newer versions of SuSE Linux and the problem is too easy to reproduce and
> VERY dangerous I think alerting people to this problem is in order.
> 

Sorry, a quick attempt at reproducing on 2.2.17 and 2.2.19 kernels did not
cause an oops.  Could you please send me a decoded version of the oops to
help track things down?

thanks,
Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Compatibility issue with 2.2.19pre7

[Alan Cox]

> is this part of 2.2.19pre7 really a good idea? Even in 2.4.0 the size
> field is still a short.

It needs to change in 2.4 as well. The cast of data to a struct isnt portable
to all architectures.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Compatibility issue with 2.2.19pre7

[Hubert Mantel]

Hi,

is this part of 2.2.19pre7 really a good idea? Even in 2.4.0 the size
field is still a short.
  -o)
Hubert Mantel  Goodbye, dots...   /\\
 _\_v


diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla/include/linux/nfs.h linux.19p7/include/linux/nfs.h
--- linux.vanilla/include/linux/nfs.h   Mon Dec 11 22:13:07 2000
+++ linux.19p7/include/linux/nfs.h  Wed Jan  3 00:58:38 2001
@@ -94,7 +94,7 @@
  */
 #define NFS_MAXFHSIZE  64
 struct nfs_fh {
-   unsigned short  size;
+   unsigned intsize;
unsigned char   data[NFS_MAXFHSIZE];
 };
 

Re: Ftape bug

[Mikael Pettersson]

On Tue, 9 Jan 2001, Tony Sumner wrote:

>I have a problem with ftape. What happened was that I had a backup on
>QIC80 tape that I made from Red Hat 5.2 and I (foolishly?) installed
>SuSE 7.0. I then found I could not read the tape with the newer version
>of ftape. 
>...
>Kernel version: was 2.0.36, now 2.2.16
>
>ftape version: 3.04d
>...
>what went wrong: tob reported 'No input'. The log in /var/spool/messages
>had a report from ftape to say that it was looking at a 
>new cartridge. An extract from the log is below. It was not
>a new cartridge -- I have been able to read it by reloading
>kernel 2.0.36 and the corresponding version 2.08 of ftape. 

Right. I'm pretty sure ftape-3.04d (as included in current 2.2 and 2.4
kernels) doesn't maintain read-compatibility with ftape-2.08. (See
Documentation/ftape.txt "Changes", and drivers/char/ftape/RELEASE-NOTES
about "sftape" being gone.)

I think your best bet is to read the tape using your 2.0.36 kernel
with ftape 2.08, reboot into 2.2.16, format the tape (or get a new one),
and then dump the data again using ftape 3.04d. Oh, and DON'T use the
built-in compression support. It's gone in ftape 4 :-)

>I am not a subscriber to this mailing list so I was advised to ask
>you to Cc any reply to me at [EMAIL PROTECTED]

/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Ingo Molnar]

On Tue, 9 Jan 2001, Hubert Mantel wrote:

> Right, but now there is a problem: Software RAID. The RAID code of
> 2.4.0 is not backwards compatible to the one in 2.2.18; if somebody
> has used 2.4.0 on softraid and discovers some problem, he can not
> switch back to some official 2.2 kernel. [...]

that is simply not true - at least for the RAID0 and LINEAR mdtools
arrays. You can start up 'new' RAID devices via mdtools just fine, even if
these new devices have RAID-superblocks. (because those superblocks are at
the end of the device, and ext2fs knows the true size of the filesystem.)

you have to keep two sets of configuration files (/etc/raidtab and
/etc/mdtab), but that is not new nor unreasonable. The tools do not clash
either.

[ the only category impacted are people who are still using the
RAID1/RAID4,5 code in the stock 2.2 kernel - i do believe the number of
these people is very low, and they should imminently upgrade to the 0.90
driver anyway, for stability and data integrity reasons. ]

Ingo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

{PATCH] megaraid.c is broken in 2.4.0

[Anwar Payyoorayil]

Checking for the return value of I/O allocation is reversed. 

Patch against 2.4.0 follows. Definitely 2.4.1 material !!

--- linux/drivers/scsi/megaraid.c.orig  Wed Dec  6 14:06:18 2000
+++ linux/drivers/scsi/megaraid.c   Tue Jan  9 18:09:34 2001
@@ -1527,7 +1527,7 @@
 megaCtlrs[numCtlrs++] = megaCfg; 
 if (flag != BOARD_QUARTZ) {
   /* Request our IO Range */
-  if (request_region (megaBase, 16, "megaraid")) {
+  if (!request_region (megaBase, 16, "megaraid")) {
printk (KERN_WARNING "megaraid: Couldn't register I/O range!" CRLFSTR);
scsi_unregister (host);
continue;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18 and EMU10K1 problems...

[Mikael Pettersson]

On Mon, 8 Jan 2001, Taner Halicioglu wrote:

>I probably missed a message or note or something about this, but when I went
>from 2.2.17 to 2.2.18, my sound card (SB Live!) stopped working.  It seems
>that in 2.2.18, it gets detected TWICE:
>
>
>kernel: Linux version 2.2.18
>[...]
>kernel: Creative EMU10K1 PCI Audio Driver, version 0.7, 20:05:23 Jan  7 2001 
>kernel: emu10k1: EMU10K1 rev 5 model 0x21 found, IO at 0xb400-0xb41f, IRQ 10 
>[... IDE, floppy, SCSI, eth0, partition check ...]
>kernel: Creative EMU10K1 PCI Audio Driver, version 0.7, 20:05:23 Jan  7 2001 
>

Known problem. Fixed in 2.2.19pre3.

/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.19pre6aa1 degraded performance for me...

[Andrea Arcangeli]

On Wed, Jan 10, 2001 at 01:07:55AM +0100, Sasi Peter wrote:
> I thought it over again. I still have to say it is a nonsense for a kernel
> not to  have _anything_ (zero pages) currently unused swapped out under
> such an I/O load!

Could you generate some furhter memory pressure to see what happens? Do you
confirm that you get the same performance as with your previous kernel if the
idle servers gets swapped out or if you shutdown them?

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Anybody got 2.4.0 running on a 386 ?

[Ingo Molnar]

you should also try to access the mem_map variable directly, in some
simple way. Could you print out the value of mem_map btw.? [This should
rule out any compiler interaction.]

Ingo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT]: DRI doesn't work on 2.4.0 but does on prerelease-ac5

[Ragnar Hojland Espinosa]

On Mon, Jan 08, 2001 at 04:37:32PM -0800, J Sloan wrote:
> Ragnar Hojland Espinosa wrote:
> > Well, the real problem is that (at least Voodoo3) DRI didn't work _before_
> > with the "latest" test and pre kernels, and X < 4.0.2 (unless there was some
> > combination I didn't manage to find) even if it was using the correct
> > library.

> That's odd, perhaps we should compare notes -

Seeing that it _finally_ worked (that qbert spongies xscreensaver thing is
hilarious:) I cleaned up all the logs, along with the mesas and glides
builds .. so right now all I have is a working setup (which I can't complain
about)

> I have been getting good accelerated 3D from my voodoo3
> since around 2.3.36, except for one brief period around
> 2.3.99-something where some critical kernel code changed.

IIRC I started trying to make it work around 2.3.99 but wasn't as fortunate
as you since as mentioned it just refused to work.
 
> BTW I am using the X server from 3dfx.com -

Ah, that could have something to do with it, because I always used the
(mirrorerd) xfree86.org binaries.
-- 
/|  Ragnar Højland Freedom - Linux - OpenGL  Fingerprint  94C4B
\ o.O|   2F0D27DE025BE2302C
 =(_)=  "Thou shalt not follow the NULL pointer for  104B78C56 B72F0822
   U chaos and madness await thee at its end."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Anybody got 2.4.0 running on a 386 ?

[Ingo Molnar]

On Wed, 10 Jan 2001, Robert Kaiser wrote:

> Sorry, no ext2fs in this kernel (it is for a diskless embedded
> system). I seem to recall though that the problem at one point
> magically went away when I disabled the FPU emulation, but I have not
> been able to reproduce this recently, so I'm not sure. Making minor
> changes to the kernel code (such as adding/removing some test-prints)
> certainly does not affect the behavior.

math-FPU emulation takes up quite some space in the kernel image, so this
could indeed be the case. Could you disable any non-boot-essential
subsystem (networking, or the serial driver, or anything else), to
significantly reduce the image size?

> > Or if that part is not mapped
> > correctly (which does happen sometimes as well).
>
> What could I do to check/fix this ?

i had this a couple of times while doing the 3-level pagetables and
related highmem stuff (and i might even have added this bug ...), and
typically i just printed out the pagetables to a serial console and
analyzed them manually :-|

> > and are you sure it crashes there? [are you putting delays between your
> > printouts?]
>
> I have put a "halting statement" (i.e. "while(1);") after my printouts to make
> sure execution does not go any further than that point. I moved this halting
> statement ahead in the code line by line until the crash would occur again.
> So, yes, I am pretty sure.

(okay, that certainly is a proof. I had to ask.)

> > it accesses mem_map variable, which is near to the end of the kernel
> > image, so it could indeed something of that sort. An uncompressed kernel
> > image (including the data area) must not be bigger than 4MB (IIRC).
>
> According to my System.map file, mem_map is at 0xc0244f78. Does that help ?

not really. Could you write a small function that just reads the kernel
image from the first symbol to the last one, and see whether it crashes?
(read it into a volatile variable to make sure GCC reads it.) Kernel image
goes from _stext to _end - you can access it with something like this:

void test_image (void)
{
extern char _stext;
extern char _end;

volatile char data;
char *ptr = &_stext;

while (ptr < _end)
data = *ptr++;
}

another problem could be if the kernel image is in a place that is somehow
invalid physical RAM. We uncompress it into address 1MB physical (and
assume there is enough space from that point on to uncompress
successfully, without actually checking it), which should work on all 'PC
architecture compatible' systems. (other bootloaders use this method
frequently as well.)

Ingo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: DRI doesn't work on 2.4.0 but does on prerelease-ac5

[Ragnar Hojland Espinosa]

On Mon, Jan 08, 2001 at 10:45:09PM +, Michael D. Crawford wrote:
> glxinfo says dri is not available if I remove the library as I did.  So I
> rebuilt Mesa and reinstalled it.  The full output of glxinfo on my machine
> follows.  Note that it says "direct rendering: Yes" but the version strings
> don't match.  Does that indicate the problem?
> 

FWIW, this works:

server glx vendor string: SGI
server glx version string: 1.2
client glx vendor string: SGI
client glx version string: 1.2
OpenGL vendor string: VA Linux Systems, Inc.
OpenGL renderer string: Mesa DRI Voodoo3 20001101
OpenGL version string: 1.2 Mesa 3.4

> server glx vendor string: Brian Paul
> server glx version string: 1.3 Mesa 3.4
> client glx vendor string: Brian Paul
> client glx version string: 1.2 Mesa 3.4
> OpenGL vendor string: Brian Paul
> OpenGL renderer string: Mesa X11
> OpenGL version string: 1.2 Mesa 3.4

-- 
/|  Ragnar Højland Freedom - Linux - OpenGL  Fingerprint  94C4B
\ o.O|   2F0D27DE025BE2302C
 =(_)=  "Thou shalt not follow the NULL pointer for  104B78C56 B72F0822
   U chaos and madness await thee at its end."   hkp://keys.pgp.com

Handle via comment channels only.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Anybody got 2.4.0 running on a 386 ?

[Alex Buell]

On Wed, 10 Jan 2001, Robert Kaiser wrote:

> I have put a "halting statement" (i.e. "while(1);") after my printouts
> to make sure execution does not go any further than that point. I
> moved this halting statement ahead in the code line by line until the
> crash would occur again. So, yes, I am pretty sure.

Here's a tip for anyone who has to track down bugs of this nature. To
greatly speed up work, just use a binary search technique. That is, go to
the section of code that's causing problem, put a breakpoint or similiar
half-way. If it dies before that point, move it back half way, after that
point, move it forwards half way. Iterate until you find the place.

Cheers,
Alex
-- 
If PacMan had affected us as kids we'd be running around in
dark rooms, munching pills and listening to electronic music.

http://www.tahallah.clara.co.uk

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4.0-ac4

[J . A . Magallon]

Compiling kernel/ksyms.c:

ksyms.c:209: warning: type defaults to `int' in declaration of `EXPORT_SYKBOL'
ksyms.c:209: warning: parameter names (without types) in function declaration
ksyms.c:209: warning: data definition has no type or storage class

patch-2.4.0-ac4.gz, line 195029:

 EXPORT_SYMBOL(generic_buffer_fdatasync);
+EXPORT_SYKBOL(generic_open_file);

Happy typo

-- 
J.A. Magallon  $> cd pub
mailto:[EMAIL PROTECTED]  $> more beer

Linux werewolf 2.4.0-ac4 #1 SMP Mon Jan 8 22:10:06 CET 2001 i686

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.19pre6aa1 degraded performance for me...

[Sasi Peter]

On Tue, 9 Jan 2001, Sasi Peter wrote:
> On Tue, 9 Jan 2001, Andrea Arcangeli wrote:
> > On Mon, Jan 08, 2001 at 10:46:29PM +0100, Sasi Peter wrote:
> > > What I had w/2.2.18pre19 (+raid+ide):
> > > ~80MB more in cache and ~80MB swapped out (eg. currently unused notes
> > > server and squid) There is enough of swap over 3 disks (like the
> > > raid), so I did not bother disabling squid and notes, since - I thought -
> > > they would only take up some swap unused.
> > There are many variables. However I guess the slowdown is because your idle
> > apps didn't got swapped out in favour of cache as you noticed. An aggressive
> > aging algorithm would probably fix that but it then would hurt other cases
> > (after you don't need a frequenty accessed part of filesystem cache anymore it
> > would take ages before it gets collected potentially causing an unnecessary
> > swapout storms because the kernel doesn't know you don't need such cache
> > anymore).  Furthmore if notes and squid are rarely running but they provides
> > critical services if they would go totally into swap in favour of fs cache you
> > would get very bad latencies the first time somebody connects to the server. So
> > the fix I suggest you is to buy more ram or to shutdown squid and notes. Than
> Oh well I thought 384MB should be enought for everyone aiming at this
> performance (almost TM ;). At least it would up till now :(
> > you may as well see a performance improvement compared to 2.2.18pre19
> > (+raid+ide).  Otherwise you can push the machine low on memory a bit until they
> > both goes totally into swap (check with `ps v`). Hope this helps.
> I'll try this, thanks. (so no echo '1 23 456' >/proc/sys/vm/...?)

I thought it over again. I still have to say it is a nonsense for a kernel
not to  have _anything_ (zero pages) currently unused swapped out under
such an I/O load!

-- 
SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: wild gettimeofday on smp under 2.2.18

[Peter T. Breuer]

"Alan Cox wrote:"
> Doesnt seem very wild to me, but something did go back 3uS which would imply
> the CPU tsc's are not synched. 2.2 doesnt like that, Boot with 'notsc' and
> repeat the experiment

No change with that, as you already know.  But I just noticed that the
ekernel was compiled for i386.  I've recompiled 2.2.18 for i686, and
this comes out of the boot messages:

  checking TSC synchronization across CPUs: 
  BIOS BUG: CPU#0 improperly initialized, has 2045320 usecs TSC skew!  FIXED.
  BIOS BUG: CPU#1 improperly initialized, has -2045320 usecs TSC skew!  FIXED.
  PCI: PCI BIOS revision 2.10 entry at 0xf0730

This is the ASUS BX dual board with onboard scsi.

But the FIXED above doesn't seem to be true. I still get results like
those below from gettimeofday calls every five seconds. Clearly two
mixed sequences ..

  978042124  !
  978042135*
  978042134  !
  978042139  !
  978042144  !
  978042149  !
  978042158*
  978042159  !
  978042164  !
  978042169  !
  978042176

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Anybody got 2.4.0 running on a 386 ?

[Robert Kaiser]

On Die, 09 Jan 2001 you wrote:
> On Tue, 9 Jan 2001, Robert Kaiser wrote:
> 
> > Now comes the amazing (to me) part: I split the above statement up into:
> >
> > temp = mk_pte_phys(__pa(vaddr), PAGE_KERNEL);
> > *pte = temp;
> 
> this is almost impossible (except some really weird compiler bug) - unless
> the mem_map address is invalid. This could happen if your kernel image is
> *just* too large. Do things improve if you disable eg. ext2fs support (i
> know, but should be enough to boot).

Sorry, no ext2fs in this kernel (it is for a diskless embedded system). I seem
to recall though that the problem at one point magically went away when I
disabled the FPU emulation, but I have not been able to reproduce this
recently, so I'm not sure. Making minor changes to the kernel code (such as
adding/removing some test-prints) certainly does not affect the behavior.

> Or if that part is not mapped
> correctly (which does happen sometimes as well).

What could I do to check/fix this ? 

> 
> and are you sure it crashes there? [are you putting delays between your
> printouts?]

I have put a "halting statement" (i.e. "while(1);") after my printouts to make
sure execution does not go any further than that point. I moved this halting
statement ahead in the code line by line until the crash would occur again.
So, yes, I am pretty sure.

> 
> > where temp is declared "volatile pte_t". I inserted test-prints between the
> > above two lines. Accoding to that, the _first_ line , i.e. the evaluation of the
> > mk_pte_phys() macro is causing the crash!
> 
> it accesses mem_map variable, which is near to the end of the kernel
> image, so it could indeed something of that sort. An uncompressed kernel
> image (including the data area) must not be bigger than 4MB (IIRC).

According to my System.map file, mem_map is at 0xc0244f78. Does that help ?




Robert Kaiser email: [EMAIL PROTECTED]
SYSGO RTS GmbH
Am Pfaffenstein 14phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany   fax:   (49) 6136 9948-10
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Linus Torvalds]

On Wed, 10 Jan 2001, Jakob Østergaard wrote:
> 
> Besides, most people using Software RAID have been using 0.90 for
> at least two years - so I doubt this would have been much of a problem
> if the 0.90 patches weren't available for 2.2, which they are.

This is probably th eimportant part. Most heavy RAID 2.2.x users have in
fact probably already used the "new" 2.4.x interface for some time.

I do agree with Alan, though: the decision on making that the _official_
2.2.x interface is a nasty decision. It will screw some people, and they
would be right in being unhappy about interface changes in the middle of a
stable kernel release.

For 2.2.x I suspect that 0.90 should continue to just be a (common) extra
patch.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1

[Andrea Arcangeli]

On Tue, Jan 09, 2001 at 09:10:24PM +0100, Ingo Molnar wrote:
> 
> On Tue, 9 Jan 2001, Andrea Arcangeli wrote:
> 
> > BTW, I noticed what is left in blk-13B seems to be my work (Jens's
> > fixes for merging when the I/O queue is full are just been integrated
> > in test1x).  [...]
> 
> it was Jens' [i think those were implemented by Jens entirely]
> batch-freeing changes that made the most difference. (we did

Confirm, the bach-freeing was Jens's work.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Set ownership correctly for MPU401 synth operations

[Chris Rankin]

Hi,

This patch makes the mpu401_synth_operations structure respect
attach_mpu401()'s "owner" parameter. This should prevent more sound
module from being accidentally unloaded.

Cheers,
Chris


--- linux-vanilla/drivers/sound/mpu401.cFri Jan  5 23:14:08 2001
+++ linux-2.4.0-ac3/drivers/sound/mpu401.c  Tue Jan  9 23:41:43 2001
@@ -1030,6 +1030,8 @@
(char *) _synth_proto,
 sizeof(struct synth_operations));
}
+   if (owner)
+   mpu401_synth_operations[m]->owner = owner;
 
memcpy((char *) _midi_operations[m],
   (char *) _midi_proto,

Re: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1

[Linus Torvalds]

On Tue, 9 Jan 2001, Benjamin C.R. LaHaise wrote:

> On Tue, 9 Jan 2001, Linus Torvalds wrote:
> 
> > The _lower-level_ stuff (ie TCP and the drivers) want the "array of
> > tuples", and again, they do NOT want an array of pages, because if
> > somebody does two sendfile() calls that fit in one packet, it really needs
> > an array of tuples.
> 
> A kiobuf simply provides that tuple plus the completion callback.  Stick a
> bunch of them together and you've got a kiovec.  I don't see the advantage
> of moving to simpler primatives if they don't provide needed
> functionality.

Ehh.

Let's re-state your argument:

 "You could have used the existing, complex and cumbersome primitives that
  had the wrong semantics. I don't see the advantage of pointing out the
  fact that those primitives are badly designed for the problem at hand 
  and moving to simpler and better designed primitives that fit the
  problem well"

Would you agree that that is the essense of what you said? And if not,
then why not?

> Please tell me what you think the right interface is that provides a hook
> on io completion and is asynchronous.

Suggested fix to kiovec's: get rid of them. Immediately. Replace them with
kiobuf's that can handle scatter-gather pages. kiobuf's have 90% of that
support already.

Never EVER have a "struct page **" interface. It is never the valid thing
to do. You should have

struct fragment {
struct page *page;
__u16 offset, length;
}

and then have "struct fragment **" inside the kiobuf's instead. Rename
"nr_pages" as "nr_fragments", and get rid of the global offset/length, as
they don't make any sense. Voila - your kiobuf is suddenly a lot more
flexible.

Finally, don't embed the static KIO_STATIC_PAGES array in the kiobuf. The
caller knows when it makes sense, and when it doesn't. Don't embed that
knowledge in fundamental data structures.

In the meantime, I'm more than happy to make sure that the networking
infrastructure is sane. Which implies that the networking infrastructure
does NOT use kiovecs.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1

[Andrea Arcangeli]

On Wed, Jan 10, 2001 at 12:34:35AM +0100, Jens Axboe wrote:
> Ah I see. It would be nice to base the QUEUE_NR_REQUEST on something else
> than a static number. For example, 3000 per queue translates into 281Kb
> of request slots per queue. On a typical system with a floppy, hard drive,
> and CD-ROM it's getting close to 1Mb of RAM used for this alone. On a
> 32Mb box this is unaccebtable.

Yes of course. Infact 3000 was just the number I choosen when doing the
benchmarks on a 128Mbox. Things needs to be autotuning and that's not yet
implemented. I meant 3000 to tell how such number can grow. Right now if you
use 3000 you will need to lock 1.5G of RAM (more than the normal zone!) before
you can block with the 512K scsi commands.  This was just to show the rest of
the blkdev layer was obviously restructured.  On a 8G box 1 requests
would probably be a good number.

> Yes I see your point. However memory shortage will fire the queue in due
> time, it won't make the WRITE block however. In this case it would be

That's the performance problem I'm talking about on the lowmem boxes. Infact
this problem will happen in 2.4.x too, just less biased than with the
512K scsi commands and by you increasing the number of requests from 256 to 512.

> bdflush blocking on the WRITE's, which seem exactly what we don't want?

In 2.4.0 Linus fixed wakeup_bdflush not to wait bdflush anymore as I suggested,
now it's the task context that sumbits the requests directly to the I/O queue
so it's the task that must block, not bdflush. And the task will block correctly
_if_ we unplug at the sane time in ll_rw_block.

> So you imposed a MB limit on how much I/O would be outstanding in
> blkdev_release_request? Wouldn't it make more sense to move this to at

No absolutely. Not in blkdev_release_request. The changes there
are because you need to somehow do some accounting at I/O completion.

> get_request time, since with the blkdev_release_request approach you won't

Yes, only ll_rw_block uplugs, not blkdev_release_request.  Obviously since the
latter runs from irqs.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Jakob Østergaard]

On Tue, Jan 09, 2001 at 02:54:44PM +, Alan Cox wrote:
> > some official 2.2 kernel. In order to make it possible to switch between
> > kernel releases, every vendor now really is forced to integrate the new
> > RAID0.90 code to their 2.2 kernel. IMHO this code should be integrated to
> > the next official 2.2 kernel so people can use whatever they want.
> 
> Then people using a newer 2.2 cannot go back to an older 2.2 thats really
> far far worse.

And don't forget, the 0.90 patches are available for 2.2 - so 2.2
can do 0.90 Software RAID just fine.

Besides, most people using Software RAID have been using 0.90 for
at least two years - so I doubt this would have been much of a problem
if the 0.90 patches weren't available for 2.2, which they are.

-- 

:   [EMAIL PROTECTED]   : And I see the elder races, :
:.: putrid forms of man:
:   Jakob Østergaard  : See him rise and claim the earth,  :
:OZ9ABN   : his downfall is at hand.   :
:.:{Konkhra}...:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Anybody got 2.4.0 running on a 386 ?

[Robert Kaiser]

On Mit, 10 Jan 2001 you wrote:
> How big is the kernel image? Are you making a zImage or bzImage?
> 

I'm using bzImage. It's size is 566964 bytes.

According to System.map, Symbol _end is 0xc0252cf0. That would mean
the uncompressed kernel size would be 1387760 bytes (0xc0252cf0-0xc010),
right ?


Robert Kaiser email: [EMAIL PROTECTED]
SYSGO RTS GmbH
Am Pfaffenstein 14phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany   fax:   (49) 6136 9948-10
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18 and Maxtor 96147H6 (61 GB)

[Andries . Brouwer]

From: Igmar Palsenberg <[EMAIL PROTECTED]>

> > 2.2.18 sometimes sees 61 GB, sometimes 32 GB.
> > I don't call that hard to understand.
> 
> The same kernel has varying behaviour?
> Maybe not hard to understand, but rather surprising.
> You are the first to report nondeterministic behaviour.

You're not the only one that is suprised :

1) Put disk in my machine (target machine hangs itself with the disk)
2) use setmax to set the limit to 32 GB
3) Put the disk in the target machine
4) System boots, linux sees 64GB
5) rebooted system, system hangs due to the soft clippig 'vanished'

I even had occurences of the kernel setmax message showing up, and after a
plain reboot it didn't.

It beats me.. I can't explain, and the machine is rock solid now.

Probably you confused the proper way to use ibmsetmax with
the proper way to use setmax. For setmax, and a Maxtor disk,
you do not use a different machine, put the jumper to clip,
now the boot succeeds, and you let Linux unclip.
Either with a patched kernel that knows about these things
or with a utility run from a boot script.
(It is most convenient to have a partition boundary where
the jumper clips, so that with old kernels and without running
the utility you also have a valid filesystem.)

Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: USB problems with 2.4.0

[Dunlap, Randy]

What kind of USB host controller is it?
Maybe there are some issues with it.

Maybe 'lspci -vv'...

~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
---

> From: Adam Huffman [mailto:[EMAIL PROTECTED]]
> 
> System is a KA7-100, sole USB peripheral is a Logitech MouseMan Wheel.
> 
> If I use the uhci driver, it doesn't initialise properly (there is a
> message along the lines of "something bad happened".  If I use the
> usb-uhci driver, I frequently get an oops if I move the mouse during
> bootup.
> 
> If anyone is interested I will try to obtain a decoded oops report.
> 
> I've had this problem for a while and have reported it here before, as
> well as to one of the USB maintainers, but with no result so far.
> 
> 
> Adam
> -

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

major security bug in reiserfs (may affect SuSE Linux)

[Marc Lehmann]

We are still investigating, but there seems to be a major security problem
in at least some versions of reiserfs. Since reiserfs is shipped with
newer versions of SuSE Linux and the problem is too easy to reproduce and
VERY dangerous I think alerting people to this problem is in order.

We have tested and verified this problem on a number of different systems
and kernels 2.2.17/2.2.8 with reiserfs-3.5.28 and probably other versions.

Basically, you do:

mkdir "$(perl -e 'print "x" x 768')"

I.e. create a very long directory. The name doesn't seem to be of
relevance (we found this out by doing mkdir "$(cat /etc/hosts)" for other
tests). This works.  The next ls (or echo *) command will segfault and the
kernel oopses. all following accesses to the volume in question will oops
and hang the process, even afetr a reboot.

reiserfsck (the filesystem check program) does _NOT_ detect or solve this
problem:

Replaying journal..ok
Checking S+tree..ok
Comparing bitmaps..ok

But fortunately, rmdir  works and seems to leave the filesystem
undamaged.

Since a kernel oops results (see below), this indicates a buffer overrun
(the kernel jumps to address 78787878, which is "") inside the kernel,
which is of course very nasty (think ftp-upload!) and certainly gives you
root access from anywhere, even from inside a chrooted environment. We
didn't pursue this further.

The best workaround at this time seems to be to uninstall reiserfs
completely or not allow any user access (even indirect) to these volumes.
While this individual bug might be easy to fix, we believe that other,
similar bugs should be easy to find so reiserfs should not be trusted (it
shouldn't be trusted to full user access for other reasons anyway, but it
is still widely used).

Unable to handle kernel paging request at virtual address 78787878
current->tss.cr3 = 0d074000, %cr3 = 0d074000
*pde = 
Oops: 0002
CPU:0
EIP:0010:[]
EFLAGS: 00010282
eax:    ebx: bfffe78c   ecx:    edx: bfffe78c
esi: ccbddd62   edi: 78787878   ebp: 0300   esp: ccbddd3c
ds: 0018   es: 0018   ss: 0018
Process bash (pid: 292, process nr: 54, stackpage=ccbdd000)
Stack: c013f66a ccbddf6c cd10 ccbddd62 030c c0136d49 0700 2013 
   1000 7878030c 78787878 78787878 78787878 78787878 78787878 78787878 
   78787878 78787878 78787878 78787878 78787878 78787878 78787878 78787878 
Call Trace: [] [] 
Code: 89 1f 8b 44 24 18 29 47 08 31 c0 5b 5e 5f 5d 81 c4 2c 01 00 


-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Subtle MM bug (really 830MB barrier question)

[Wayne Whitney]

On Tue, 9 Jan 2001, Szabolcs Szakacsits wrote:

> Wayne, the patch below should fix your barrier problem [1 GB physical
> memory configuration].

First, I just wanted to thank you and everyone else (Linus, Andrea, Dan
Maas, Rik and others) who has responded to my emails.  You guys are
wonderful!

On Tue, 9 Jan 2001, Dan Maas wrote:

> OK it's fairly obvious what's happening here. Your program is using
> its own allocator, which relies solely on brk() to obtain more memory.

OK, the statically linked binary I have produces a simpler /proc/pid/maps,
here it is (before I actually try to create any big objects in memory):

08048000-08afb000 r-xp  03:07 64318  /usr/local/magma-2.7/magma.exe
08afb000-08c3e000 rw-p 00ab2000 03:07 64318  /usr/local/magma-2.7/magma.exe
08c3e000-0bc54000 rwxp  00:00 0
4000-40001000 rw-p  00:00 0
bfffd000-c000 rwxp e000 00:00 0

If I understand correctly, the first two lines are the executable
(although I don't know why it shows up twice), the third line is the heap
for this program, the fourth line is where mmap stuff starts and the fifth
line is the boundary between the process address space and the kernel
address space.

First question:  for this statically linked binary, nothing is really
being mmap'ed, is there any way that I can arrange, for this process only,
to get rid of the fourth line?  This would be the ideal solution.

Szabolcs's suggestion (and Mark Hahn's privately, as well) of modifying
TASK_UNMAPPED_BASE does work for me.  Unfortunately, on the same machine
I'd like to both run programs that use brk() allocation and that use
mmap() allocation, so the best I can do is change TASK_UNMAPPED_BASE to
1.5GB from 1GB, this allows a bit under 1.5GB for brk() and 1.5GB() for
mmap().

Second question:  if I understand correctly, the start of the kernel
process space is controlled by PAGE_OFFSET, and under CONFIG_NOHIGHMEM,
the kernel maps all the physical RAM into its address space.  I guess
128MB of this space is used for the 2.4.0 kernel itself, so that the
maximum physical RAM under 2.4.0 with PAGE_OFFSET set to 3GB is 896MB.
One of my machines has 1024MB of RAM, so can I just decrease PAGE_OFFEST
by 128MB to be able to use all of it?

Thanks again,
Wayne





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Adaptec AIC7XXX version 6.08BETA released

[Justin T. Gibbs]

Version 6.08BETA of the Adaptec sponsored and supported AIC7XXX
dirver is now available.  Patches against 2.4.0 and 2.2.18 are
provided here:

http://people.FreeBSD.org/~gibbs/linux/

If you are using hardware supported by the aic7xxx driver,
I would appreciate feedback on the new driver.

Changelog:

o Honor selection timeout settings set by the user.

o Correct a bug that could cause us to fail a command
  that underflowed due to a check condition.  We now
  return DID_OK in this case with the sense information
  returned.

o Added initial /proc support.

o Generate module in SCSI directory so it can be
  named just like its predecessor.

o Complete big endian support (untested).

o Split out our host template definition so we don't
  muck up the namespace when our template is included
  in hosts.c

--
Justin

Justin T. Gibbs
OpenSource Embedding
Adaptec Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

truncate() error values (was Re: Floppy disk strange behavior)

[Alexander Viro]

On Wed, 10 Jan 2001 [EMAIL PROTECTED] wrote:

> >> dd: advancing past 1 blocks in output file `/dev/fd0': Permission denied
> 
> > dd bug. It tries to ftruncate() the output file and gets all upset when
> > kernel refuses to truncate a block device (surprise, surprise).
> 
> Yes. But EPERM means that something is wrong with privileges.
EACCES, actually.
> One would expect EINVAL or so when something is wrong with the
> way the routine was called.

Oh, agreed. Patch I've sent to Linus and posted on l-k more than a month ago:

diff -urN rc12-pre5/fs/open.c rc12-pre5-truncate/fs/open.c
--- rc12-pre5/fs/open.c Wed Nov 29 21:37:31 2000
+++ rc12-pre5-truncate/fs/open.cTue Dec  5 14:53:59 2000
@@ -102,7 +102,12 @@
goto out;
inode = nd.dentry->d_inode;
 
-   error = -EACCES;
+   /* For directories it's -EISDIR, for other non-regulars - -EINVAL */
+   error = -EISDIR;
+   if (S_ISDIR(inode->i_mode))
+   goto dput_and_out;
+
+   error = -EINVAL;
if (!S_ISREG(inode->i_mode))
goto dput_and_out;
 
@@ -163,7 +168,7 @@
goto out;
dentry = file->f_dentry;
inode = dentry->d_inode;
-   error = -EACCES;
+   error = -EINVAL;
if (!S_ISREG(inode->i_mode) || !(file->f_mode & FMODE_WRITE))
goto out_putf;
error = -EPERM;

That's test12-pre5. And yes, the case of files opened with O_RDONLY should
be -EINVAL according to
* our own manpages
* POSIX
* *BSD behaviour
* Solaris behaviour
* manpages of all Unices I've seen.
-EACCES is wrong here. More logical, but...

Linus, I realize that we have a moratorium on patches. It's certainly not
a critical one, but it probably ought to be applied at some point. Could
you tell what time would be OK for resubmitting it? All it changes is
* error returned for truncate() on directories (EACCES -> EISDIR)
* error returned for truncate() on other non-file (EACCES -> EINVAL)
* error returned for ftruncate() on O_RDONLY fds (EACCES -> EINVAL)
* error returned for ftruncate() on non-files (EACCES -> EINVAL)
In all cases new error values are what we are required to do by POSIX, SuS,
our own manpages, manpages of other Unices and actual behaviour of other
Unices.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1

[Jens Axboe]

On Wed, Jan 10 2001, Andrea Arcangeli wrote:
> On Tue, Jan 09, 2001 at 09:12:04PM +0100, Jens Axboe wrote:
> > I haven't heard anything beyond the raised QUEUE_NR_REQUEST, so I'd like to
> > see what you have pending so we can merge :-). The tiotest seek increase was
> > mainly due to the elevator having 3000 requests to juggle and thus being able
> > to eliminate a lot of seeks right?
> 
> Raising QUEUE_NR_REQUEST is possible because of the rework of other parts of
> ll_rw_block meant to fix the lowmem boxes.

Ah I see. It would be nice to base the QUEUE_NR_REQUEST on something else
than a static number. For example, 3000 per queue translates into 281Kb
of request slots per queue. On a typical system with a floppy, hard drive,
and CD-ROM it's getting close to 1Mb of RAM used for this alone. On a
32Mb box this is unaccebtable.

I previously had blk_init_queue_nr(q, nr_free_slots) to eg not use that
many free slots on say floppy, which doesn't really make much sense
anyway.

> > I don't see any lowmem problems -- if under pressure, the queue should be
> > fired and thus it won't get as long as if you have lots of memory free.`
> 
> A write(2) shouldn't cause the allocator to wait I/O completion. It's the write
> that should block when it's only polluting the cache or you'll hurt the
> innocent rest of the system that isn't writing.
> 
> At least with my original implementation of the 512K large scsi command
> support that you merged, before a write could block you first had to generate
> at least 128Mbyte of memory _locked_ all queued in the I/O request list waiting
> the driver to process the requests (only locked, without considering
> the dirty part of memory).
> 
> Since you raised from 256 requests per queue to 512 with your patch you
> may have to generate 256Mbyte of locked memory before a write can block.
> 
> This is great on the 8G boxes that runs specweb but this isn't that great on a
> 32Mbyte box connected incidentally to a decent SCSI adapter.

Yes I see your point. However memory shortage will fire the queue in due
time, it won't make the WRITE block however. In this case it would be
bdflush blocking on the WRITE's, which seem exactly what we don't want?

> I say "may" because I didn't checked closely if you introduced any kind of
> logic to avoid this. It seems not though because such a logic needs to touch at
> least blkdev_release_request and that's what I developed in my tree and then I
> could raise the number of I/O request in the queue up to 1 if I wanted
> without any problem, the max-I/O in flight was controlled properly. (this
> allowed me to optimize away not 256 or in your case 512 seeks but 1 seeks)
> This is what I meant with exploiting the elevator. No panic, there's no buffer
> overflow there ;)

So you imposed a MB limit on how much I/O would be outstanding in
blkdev_release_request? Wouldn't it make more sense to move this to at
get_request time, since with the blkdev_release_request approach you won't
catch lots of outstanding lock buffers before you start releasing one of
them, at which point it would be too late (it might recover, but still).


-- 
* Jens Axboe <[EMAIL PROTECTED]>
* SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

USB problems with 2.4.0

[Adam Huffman]

System is a KA7-100, sole USB peripheral is a Logitech MouseMan Wheel.

If I use the uhci driver, it doesn't initialise properly (there is a
message along the lines of "something bad happened".  If I use the
usb-uhci driver, I frequently get an oops if I move the mouse during
bootup.

If anyone is interested I will try to obtain a decoded oops report.

I've had this problem for a while and have reported it here before, as
well as to one of the USB maintainers, but with no result so far.


Adam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

No Subject

[Robert Kaiser]

Hi,

In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Timur Tabi) writes:
> ** Reply to message from Robert Kaiser <[EMAIL PROTECTED]> on Tue, 9 Jan 2001
> 23:17:11 +0100
> 
> 
>> temp = mk_pte_phys(__pa(vaddr), PAGE_KERNEL);
>>  *pte = temp;
>> 
>> where temp is declared "volatile pte_t". I inserted test-prints between the
>> above two lines. Accoding to that, the _first_ line , i.e. the evaluation of the
>> mk_pte_phys() macro is causing the crash!
> 
> In that case, it's either a compiler bug or a race condition.
> 
> Compiling this source file with the -S option will generate an assembly output.
> The output should be the same regardless of whether you use the temp variable or
> not.  That will answer the question as to what the cause is.  If you're lucky,
> it's a compiler bug, because they're easier to fix.
> 
> 
I thought that by declaring temp "volatile" I could force the compiler to not
optimize it away, i.e. make sure that the evaluation of the mk_pte_phys()
macro and the assignment to *pte indeed get seperated. Is this not the case ?

Anyway, the actual code I'm using has debug output in between the lines, so it
looks more like this:

*((volatile unsigned char*)0xb8000) = '1';
temp = mk_pte_phys(__pa(vaddr), PAGE_KERNEL);
*((volatile unsigned char*)0xb8000) = '2';
*pte = temp;
*((volatile unsigned char*)0xb8000) = '3';

When the system crashes, just before the BIOS clears the screen, I can clearly
see a '2' in the upper left corner of the screen.


Robert Kaiser email: [EMAIL PROTECTED]
SYSGO RTS GmbH
Am Pfaffenstein 14phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany   fax:   (49) 6136 9948-10
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/