Re: IA-32 (was Re: [PATCH] cpu detection fixes for test10-pre4)

[H. Peter Anvin]

"Barry K. Nathan" wrote:
> 
> H. Peter Anvin wrote:
> 
> > Alan Cox wrote:
> 
> [snip]
> 
> > > ia32 is an intel trademark. Using it for non intel products is probably an
> > > actionable matter ..
> > >
> >
> > Yet another reason to ignore it.
> 
> Speaking of using it for non-Intel products, this is a line from
> Documentation/Changes in Linux 2.4.0-test10-pre6:
> 
> Linux on IA-32 has recently switched from using as86 to using gas for
> 
> Should we change that to x86 or something?
> 

Since Linux generally calls this i386 throughout, I would stick with
calling it i386.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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: OOPS in nfsd, affects all 2.2 and 2.4 kernels

[Neil Brown]

On Friday October 27, [EMAIL PROTECTED] wrote:
> This was first reported in 2.2.12, according to Deja. Solaris clients,
> on rare occaisons, will send some command to a linux server which
> causes a null resp->fh.fh_dentry to be passed to routines in
> /usr/src/linux/fs/nfsd/nfsxdr.c. This causes an oops, and then the nfs
> server subsystem stop functioning. A fix is to check that this is not
> null before de-referencing it in the following three routines. I
> looked and this bug is present in the latest 2.2 and 2.4 kernels.
> 
> Whatever condition causes this is very rare. We had a linux server
> supporting 100 Solaris and HP-UX boxes running flawlessly for 8
> months, then one day something triggered this bug, and it wouldn't go
> away until I implemented this fix. There were no apparent side effects
> to doing this, although you may want to print some informative message
> to try and track down the real culprit.
> 
> THis patch is against 2.2.16, but the code looks unchanged in
> 2.4.0.

Thanks for sending me this.

This problem that you are addressing is caused when solaris sends a
zero length write (I assume to implement the "access" system call, but
I haven't checked).
If you look at the code at the top of nfsd_write in nfsd/vfs.c, you
will see that if cnt (the number of bytes to write) is zero, then it
jumps straight out without setting an error or initialising fhp (by
calling nfsd_open).
As there is no error, nfsd tried to return status information (hence
the call the nfssvc_encode_attrstat) but doesn't have a valid file
handle.  So it Oopses.

The correct fix, which is in 2.4 and would have recently gone into the
2.2.18 pre-patches (but I haven't actually looked at them) is to move 
the test for (!cnt) to after the call to nfsd_open.

NeilBrown
-
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: Possible critical VIA vt82c686a chip bug (private question)

[TimO]

Vojtech Pavlik wrote:
> 
> I'm *not* sure. It just looks like a reasonable explanation. It doesn't
> happen on Intel chips and older VIA chips, it only happens on new VIA
> chips, and the code is the same all the time. Also, it happens both with
> 2.2 and 2.4 kernels ...
> 
> --
> Vojtech Pavlik
> SuSE Labs
>

Do you have a method guaranteed to reproduce this?  I have a newer VIA
chipset and haven't (yet) observed this problem.

Host bridge: VIA Technologies, Inc. VT8371 [KX133] (rev 2).
PCI bridge: VIA Technologies, Inc. VT8371 [KX133 AGP]  (rev 0).
ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South]
(rev 34).
IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 16).
Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev
48).
Multimedia audio controller: VIA Technologies, Inc. AC97 Audio
Controller (rev 32).


===
-- TimO
==++==
-
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/

update: i21143 (tulip) and 2.2.17 (upgrade to .91-g and egcs-1.1.2 seems to have fixed it)

[Clayton Weaver]

Update on the hang during ftp on stock Debian potato (2.2.17-pre6 IIRC)
with i21143 tulip pci ethernet:

I changed to gcc-2.91.66 (egcs-1.1.2; Debian afaik used gcc 2.7.2.3
or 2.95.2 to compile the pre-compiled vanilla distribution kernel in
potato) and upgraded the 2.2.17-pre_something kernel to the final 2.2.17
(with the .91-g tulip driver), using binutils-2.9.1.0.25, glibc-2.1.3,
and compiled a monolithic kernel while running 2.0.38.

Everything seems ok (simple needs). Too many changes to pin down the cause
of the earlier deadlock that I reported, and it's too soon to see if there
will still be sporadic wrong ext2fs block counts at e2fsck time, but no
deadlocks so far, no oopses, ftp works, ping works, http works, etc.

So the kernel upgrade and kernel compiler change in combination is at
least much more stable, without being to say why exactly (ie "for anyone
that had doubts, there are kernels after 2.0.38 where a real tulip card
is reliable, if you have the lucky compiler").

:-),

Clayton Weaver

(Seattle)

"Everybody's ignorant, just in different subjects."  Will Rogers



-
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: atapi dvd-ram support

[Andre Hedrick]

hdparm -r0 /dev/hdc

smsc:/proc/ide/hdc # cat model driver media
MATSHITADVD-RAM LF-D210
ide-cdrom version 4.99
cdrom

smsc:/proc/ide/hdc # hdparm -r0 /dev/hdc

/dev/hdc:
 setting readonly to 0 (off)
 readonly =  0 (off)

smsc:/ # mke2fs -b 2048 /dev/hdc -m 0
mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
Filesystem label=
OS type: Linux
Block size=2048 (log=1)
Fragment size=2048 (log=1)
561152 inodes, 2236704 blocks
0 blocks (0.00%) reserved for the super user
First data block=0
137 block groups
16384 blocks per group, 16384 fragments per group
4096 inodes per group
Superblock backups stored on blocks:
16384, 49152, 81920, 114688, 147456, 409600, 442368, 802816, 1327104,
2048000

Writing inode tables: done
Writing superblocks and filesystem accounting information: done

That is how it is DONE!

On Sat, 28 Oct 2000, Hisaaki Shibata wrote:

> Hello
> 
> I did patch 2.2.17 tree with dvd-ram-2217p17.diff.bz2.
> 
> At that time, following patch is rejected.
> I think these lines should be removed from patchs.
> 
>   @@ -1329,7 +1369,7 @@
>static
> void cdrom_sleep (int time)
>  {
>  -   current->state = TASK_INTERRUPTIBLE;
>  +   __set_current_state(TASK_INTERRUPTIBLE);
>  schedule_timeout(time);
>   }
> 
> After removing these, I could make bzImage.
> 
> But I could not mkudf nor mkext2fs to my ATAPI 9.4GB new DVD-RAM drive.
> 
> dmesg shows;
> --
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> PIIX4: IDE controller on PCI bus 00 dev 39
> PIIX4: chipset revision 1
> PIIX4: not 100% native mode: will probe irqs later
> ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio
> ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
> PDC20262: IDE controller on PCI bus 00 dev 60
> PDC20262: chipset revision 1
> PDC20262: not 100% native mode: will probe irqs later
> PDC20262: ROM enabled at 0xe700
> PDC20262: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
> PDC20262: FORCING PRIMARY MODE BIT 0x00 -> 0x01 MASTER
> PDC20262: FORCING SECONDARY MODE BIT 0x00 -> 0x01 MASTER
> ide2: BM-DMA at 0xec00-0xec07, BIOS settings: hde:DMA, hdf:pio
> ide3: BM-DMA at 0xec08-0xec0f, BIOS settings: hdg:DMA, hdh:pio
> hdc: HITACHI DVD-RAM GF-2000, ATAPI CDROM drive
> hde: IBM-DTLA-305020, ATA DISK drive
> hdg: IBM-DTLA-305020, ATA DISK drive
> ide1 at 0x170-0x177,0x376 on irq 15
> ide2 at 0xdc00-0xdc07,0xe002 on irq 16
> ide3 at 0xe400-0xe407,0xe802 on irq 16
> hde: IBM-DTLA-305020, 19623MB w/380kB Cache, CHS=39870/16/63, UDMA(66)
> hdg: IBM-DTLA-305020, 19623MB w/380kB Cache, CHS=39870/16/63, UDMA(66)
> 
> [SNIP]
> 
> hdc: ATAPI DVD-ROM DVD-RAM drive, 512kB Cache, UDMA(33)
> Uniform CD-ROM driver Revision: 3.12
> VFS: Disk change detected on device ide1(22,0)
> Uniform CD-ROM driver unloaded
> --
> 
> /proc/ide/hdc/media shows;
> cdrom
> 
> How can I read/write DVD-RAM media like MO drive?
> 
> I can read/write ATAPI 5.2GB DVD-RAM media with 2.2.16 ide-scsi mode in ext2fs.
> 
> Best Regards,
> 
> 
> > I've put up patches for 2.2 and 2.4 adding native ATAPI dvd-ram support.
> > The 2.2 patch is completely untested, but the 2.4 version appears to
> > work well.
> > 
> > *.kernel.org/pub/linux/kernel/people/axboe/dvdram
> 
> -- 
>  W  [EMAIL PROTECTED]
>  |O-O|  Hisaaki Shibata
> 0(mmm)0 P-mail: 070-5419-3233IRC: #luky
>~http://his.luky.org/ last update:2000.3.12
> -
> 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
The Linux ATA/IDE guy

-
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: atapi dvd-ram support

[Hisaaki Shibata]

Hello

I did patch 2.2.17 tree with dvd-ram-2217p17.diff.bz2.

At that time, following patch is rejected.
I think these lines should be removed from patchs.

@@ -1329,7 +1369,7 @@
 static
  void cdrom_sleep (int time)
   {
   -   current->state = TASK_INTERRUPTIBLE;
   +   __set_current_state(TASK_INTERRUPTIBLE);
   schedule_timeout(time);
}

After removing these, I could make bzImage.

But I could not mkudf nor mkext2fs to my ATAPI 9.4GB new DVD-RAM drive.

dmesg shows;
--
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
PDC20262: IDE controller on PCI bus 00 dev 60
PDC20262: chipset revision 1
PDC20262: not 100% native mode: will probe irqs later
PDC20262: ROM enabled at 0xe700
PDC20262: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
PDC20262: FORCING PRIMARY MODE BIT 0x00 -> 0x01 MASTER
PDC20262: FORCING SECONDARY MODE BIT 0x00 -> 0x01 MASTER
ide2: BM-DMA at 0xec00-0xec07, BIOS settings: hde:DMA, hdf:pio
ide3: BM-DMA at 0xec08-0xec0f, BIOS settings: hdg:DMA, hdh:pio
hdc: HITACHI DVD-RAM GF-2000, ATAPI CDROM drive
hde: IBM-DTLA-305020, ATA DISK drive
hdg: IBM-DTLA-305020, ATA DISK drive
ide1 at 0x170-0x177,0x376 on irq 15
ide2 at 0xdc00-0xdc07,0xe002 on irq 16
ide3 at 0xe400-0xe407,0xe802 on irq 16
hde: IBM-DTLA-305020, 19623MB w/380kB Cache, CHS=39870/16/63, UDMA(66)
hdg: IBM-DTLA-305020, 19623MB w/380kB Cache, CHS=39870/16/63, UDMA(66)

[SNIP]

hdc: ATAPI DVD-ROM DVD-RAM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
VFS: Disk change detected on device ide1(22,0)
Uniform CD-ROM driver unloaded
--

/proc/ide/hdc/media shows;
cdrom

How can I read/write DVD-RAM media like MO drive?

I can read/write ATAPI 5.2GB DVD-RAM media with 2.2.16 ide-scsi mode in ext2fs.

Best Regards,


> I've put up patches for 2.2 and 2.4 adding native ATAPI dvd-ram support.
> The 2.2 patch is completely untested, but the 2.4 version appears to
> work well.
> 
> *.kernel.org/pub/linux/kernel/people/axboe/dvdram

-- 
 W  [EMAIL PROTECTED]
 |O-O|  Hisaaki Shibata
0(mmm)0 P-mail: 070-5419-3233IRC: #luky
   ~http://his.luky.org/ last update:2000.3.12
-
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: kernel newby help.... What's causing my Oops

[Keith Owens]

On Fri, 27 Oct 2000 02:26:10 -0400, 
David Won <[EMAIL PROTECTED]> wrote:
>Oct 22 22:37:20 phlegmish kernel: Unable to handle kernel paging request at 
>virtual address 00018486
>Oct 22 22:37:20 phlegmish kernel: EIP:
>0010:[smbfs:__insmod_smbfs_O/lib/modules/2.4.0-test8/kernel/fs/smbfs/sm+-234781/96]
>Oct 22 22:37:20 phlegmish kernel: Call Trace: 
>[smbfs:__insmod_smbfs_O/lib/modules/2.4.0-test8/kernel/fs/smbfs/sm+-220073/96] 
>[smbfs:__insmod_smbfs_O/lib/modules/2.4.0-test8/kernel/fs/smbfs/sm+-237584/96] 
>[smbfs:__insmod_smbfs_O/lib/modules/2.4.0-test8/kernel/fs/smbfs/sm+-245443/96] 
>[__fput+35/144] [_fput+17/64] [fput+18/24] [filp_close+82/92] 
>Oct 22 22:37:20 phlegmish kernel: Code: 0f b7 aa 84 40 00 00 89 ef 83 c7 04 
>89 4c 24 1c 83 c6 04 8b 
>Using defaults from ksymoops -t elf32-i386 -a i386

You did everything right, alas the data was corrupted in the log files
before you even saw it.  klogd tries to converts oops itself and far to
often it gets it wrong, yielding gibberish.  Edit /etc/rc.d/init.d/syslog
(assuming you use SysV init), change
  daemon klogd
to
  daemon klogd -x
then /etc/rc.d/init.d/syslog restart.  Any new oops will be left alone
so you will have clean data to feed to ksymoops.  When you get a clean
oops, feed it to ksymoops and mail the result to linux-kernel.

-
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: pcmcia in test10pre6

[John Kennedy]

On Fri, Oct 27, 2000 at 11:32:18AM +, Jonathan Hudson wrote:
> Previously working in test10pre*, now gives many unresolved symbols: ...

  I didn't get nearly that many.  In fact, I only got this one:

...
-o vmlinux
drivers/pcmcia/pcmcia.o: In function `CardServices':
drivers/pcmcia/pcmcia.o(.text+0x3b53): undefined reference to 
`pcmcia_request_irq'
drivers/pcmcia/pcmcia.o(__ksymtab+0x160): undefined reference to 
`pcmcia_request_irq'
make: *** [vmlinux] Error 1

  This seems to be the fatal change:

[diff -u linux-2.4.0-test10pre[56]/drivers/pcmcia/cs.c | grep _request_irq]
-int pcmcia_request_irq(client_handle_t handle, irq_req_t *req)
+static int cs_request_irq(client_handle_t handle, irq_req_t *req)

  I see it mentioned in a number of places:

drivers/net/pcmcia/ray_cs.c
drivers/pcmcia/cs.c
include/pcmcia/cs.h

  This patch compiles, but I haven't tested it yet (not home with laptop).



--- ./drivers/pcmcia/cs.c.OLD   Fri Oct 27 10:14:53 2000
+++ ./drivers/pcmcia/cs.c   Fri Oct 27 20:39:55 2000
@@ -1836,7 +1836,7 @@
 
 ==*/
 
-static int cs_request_irq(client_handle_t handle, irq_req_t *req)
+int pcmcia_request_irq(client_handle_t handle, irq_req_t *req)
 {
 socket_info_t *s;
 config_t *c;

Re: test[9-10] USB depmod unresolved symbols

[Greg KH]

Thanks Keith for that detailed description of what is going wrong, I
would have never figured that out.

On Sat, Oct 28, 2000 at 12:29:39PM +1100, Keith Owens wrote:
> 
> I will add LINK_FIRST and LINK_LAST to kbuild this weekend and
> reinstate the missing lines in drivers/usb/Makefile.  What I need from
> the USB group is a documented (i.e. *why* is this order required)
> definition of what needs to be linked first into usbdrv.o, and somebody
> we can query if there are problems in the future.  It will probably be
> as simple as

Yeah, a valid reason for LINK_FIRST and LINK_LAST!

I'll try my hand at the wording. Randy, does this look acceptable:

# usb.o contains __init usb_init which must be executed before all
# other usb __init routines, the remaining usb __init routines can be
# executed in any order.  Execution order of __init routines depends
# on link order so usb.o must be linked first.  Otherwise, the
# individual drivers will be initialized before the hub driver is,
# causing the hub driver initialization sequence to needlessly probe
# every USB driver with the root hub device.  This causes a lot of
# unnecessary system log messages, a lot of user confusion, and has
# been known to cause a incorrectly programmed USB device driver to
# grab the root hub device improperly.
# Greg Kroah-Hartman, 27 Oct 2000

LINK_FIRST := usb.o

> but you know better than I what the required order will be and why.
> Are there any other link order problems in USB?

That's the only known link problem for the USB drivers.

Thanks,

greg k-h

-- 
greg@(kroah|wirex).com
http://immunix.org/~greg

 PGP signature

RTNL assert

[Stephen E. Clark]

When I configure in Tunneling I get the following error message. Is this
normal? This with 2.4test9pre5

GRE over IPv4 tunneling driver
RTNL: assertion failed at devinet.c(775):inetdev_event
-
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/

RTNL assert

[Stephen E. Clark]

When I configure in Tunneling I get the following error message. Is this
normal?

GRE over IPv4 tunneling driver
RTNL: assertion failed at devinet.c(775):inetdev_event
-
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: Blocked processes <=> Elevator starvation?

[Jens Axboe]

On Sat, Oct 28 2000, Rui Sousa wrote:
> After adding
> 
> #define ELEVATOR_HOLE_MERGE 3
> 
> to linux/include/linux/elevator.h it compiled ok.

Oops sorry, I'm on the road so the patch was extracted
from my packet writing tree (and not my regular tree).

> There were still some stalls but they only lasted a couple of
> seconds. The patch did make a difference and for the better.

Ok, still needs a bit of work. Thanks for the feedback.

-- 
* 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/

Re: Blocked processes <=> Elevator starvation?

[Rui Sousa]

On Fri, 27 Oct 2000, Jens Axboe wrote:

...
> > So it seems the process is either in a loop in ___wait_on_page()
> > racing for the PageLock or it never wakes-up... (I guess I could add a
> > printk to check which)
> > Unfortunately I didn't find anything obviously wrong with the code.
> > I hope you can do a better job tracking the problem down.
> 
> Rik is right, just because you are seeing long waits on wait_on_page
> doesn't make it a vm problem. When a I/O on a page completes, the
> page will be unlocked and wait_on_page can grab it -- so I/O stalls
> would results in this behaviour.
> 
> Could you try this patch:
> 
> *.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.0-test10-pre6/blk-7.bz2
> 
> and see if it makes a difference?

After adding

#define ELEVATOR_HOLE_MERGE 3

to linux/include/linux/elevator.h it compiled ok.
There were still some stalls but they only lasted a couple of
seconds. The patch did make a difference and for the better.

Rui Sousa

-
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: Off-Topic (or maybe on-topic)

[Gerhard Mack]

On Fri, 27 Oct 2000 [EMAIL PROTECTED] wrote:

> If Bill said 'screw you' to the blackmailer and made the press release,
> we should see the source on web sites soon.  Then we can see how bad it
> really is.  Maybe even fix it.
> 

Or better yet: use it to write an interface spec so we can get wine to run
anything windows does.
Gerhard


--
Gerhard Mack

[EMAIL PROTECTED]

<>< As a computer I find your faith in technology amusing.

-
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] generic_serial's block_til_ready (fwd)

[Keith Owens]

On Fri, 27 Oct 2000 15:27:04 +0200 (CEST), 
Patrick van de Lageweg <[EMAIL PROTECTED]> wrote:
>This patch renames the block_til_ready of generic serial to
>gs_block_til_ready. This patch also exports the symbols needed by other
>modules with generic_serial compiled into the kernel.
>
>(it also helps when other modules have a "static block_til_ready"
>defined. This IMHO is a bug in the module-utils, but I'm told it
>cannot be fixed becuase of backwards compatibility Grrr. -- REW)

modutils for kernel 2.5 will break that backwards compatibility, it
goes all the way back to 2.0 kernels.  But if I broke backwards
compatibility just before 2.4 kernel release, there would be a lynch
mob headed my way.  In any case, block_til_ready is too generic a name
for an exported symbol.

-
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] Make agpsupport work with modversions

[Keith Owens]

On Fri, 27 Oct 2000 14:25:48 +0100, 
David Woodhouse <[EMAIL PROTECTED]> wrote:
>But in the case where there _aren't_ any functions which could usefully be 
>shared between the modules, you've got a whole extra gratuitous module 
>(What's that, 32KiB on some ARM boxen?) just to hold the registration 
>functions, which aren't needed if you just use get_module_symbol().
>
>Provide generic code for registering such stuff and it might be acceptable. 
>Otherwise, get_module_symbol is better. There's no fundamental flaw with 
>get_module_symbol() - just one or two of the current usages of it.

cc list trimmed.  Nobody has come up with a "must have" reason for
get_module_symbol and that interface is broken as designed.  I will be
adding generic inter-object registration code and removing all vestiges
of get_module_symbol this weekend.  The inter-object registration code
will allow two objects to pass data to each other, it will not matter
whether the objects are both modules, one module and one built in (in
either order) or both built in.  When modules are involved there will
be full module locking.

-
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: test[9-10] USB depmod unresolved symbols

[Keith Owens]

On Fri, 27 Oct 2000 12:55:57 -0700, 
"Dunlap, Randy" <[EMAIL PROTECTED]> wrote:
>I'm currently using 2.4.0-test10-pre6.
>Now if I am running 't10pre6' (no USB in kernel)
>and I do 'depmod -ae', I get lots of these
>"Unresolved symbol" messages from depmod.
>However, if I boot 't10pre6-kuc' (USBcore in kernel)
>and i do 'depmod -ae', it works fine, no errors.

The problem is actually caused by the drivers/usb/Makefile.  Right at
the start we have

  # Objects that export symbols.
  export-objs := usb.o

Tells the kernel build that usb.o needs compile flag -DEXPORT_SYMTAB.

  # Multipart objects.
  list-multi  := usbcore.o
  usbcore-objs:= usb.o usb-debug.o hub.o

Tells kbuild that usb.o is not a free standing module, instead usb.o,
usb-debug.o and hub.o are linked into module usbcore.o.  There is no
reference to usb.o in the rest of the Makefile, instead you have

  obj-$(CONFIG_USB)   += usbcore.o

All of this is quite normal, kbuild massages the object lists according
to whether they are being built as an object or as a module, part of
that massaging is to handle multiple objects linked into a single
object.  After all the config dependencies have been created, there is
bolierplate code to handle overlapping entries in the various variable
lists, starting with

  # Extract lists of the multi-part drivers.

However there are two lines missing from the end of this boilerplate
code.

  # Take multi-part drivers out of obj-y and put components in.
  obj-y   := $(filter-out $(list-multi), $(obj-y)) $(int-y)

Because those lines are missing, when USB is built into the kernel,
obj-y contains usbcore.o instead of its expansion (usb.o usb-debug.o
hub.o).  When kdbuild compiles the USB objects for the kernel, it does
not know about the special compile flags for usb.o.  usb.o is built as
a normal object (no -DEXPORT_SYMTAB) and linked into usbcore.o which in
turn is linked into usbdrv.o.  What should happen is that usb.o is
compiled with -DEXPORT_SYMTAB, usb-debug.o and hub.o are compiled
without -DEXPORT_SYMTAB, all three are linked directly into usbdrv.o,
The object usbcore.o should not be built when USB is in the kernel, it
is a module only object.

The incorrect compile flags on usb.o mean that instead of exporting
usb_deregister in /proc/ksyms, it exports __VERSIONED_SYMBOL(usb_deregister),
the macro does not get expanded.  This causes all the unresolved
symbols.  At first glance the fix is easy, just put the missing lines
back into Makefile, that definitely fixes the export symbol problem.

  # Take multi-part drivers out of obj-y and put components in.
  obj-y   := $(filter-out $(list-multi), $(obj-y)) $(int-y)

However USB has another problem, which is probably why those lines were
removed in the first place.  Adding $int-y to the end of the obj-y list
means that usb.o, usb-debug.o and hub.o are linked into usbdrv.o as the
last objects.  This disturbs the order of the __init routines, usb_init
in usb.o is executed last when the above lines are in Makefile.

This is a generic kbuild problem, other directories have similar link
order problems, they get around it by explicitly ordering entries in
Makefile.  This kludge will not work for USB because you have a special
case, nobody else has this order problem with a multi part object.  If
usbcore was a single source instead of being built from three sources
then the explicit order kludge would work.

The kbuild group has been discussing adding a couple of extra variables
to kbuild to solve this link order problem, LINK_FIRST and LINK_LAST.
We were going to leave it until kernel 2.5 but it looks like we need
this functionality now.  LINK_FIRST says "iff these objects are part of
O_TARGET then link them into O_TARGET before all other objects".
LINK_LAST says "iff these objects are part of O_TARGET then link them
into O_TARGET after all other objects".  The rest of the objects will
then be linked into O_TARGET in an *arbitrary* order (probably sorted
alphabetically) after LINK_FIRST and before LINK_LAST.

The only justification for LINK_FIRST is to ensure that initialisation
routines run in the correct order.  The only justification for
LINK_LAST is to put older device drivers after newer ones when the
hardware is such that both drivers would recognise it but you want the
newer driver to probe first.  The kbuild group requires that all use of
LINK_FIRST and LINK_LAST be justified and documented, to avoid
undocumented gotchas coming back to bite us.

I will add LINK_FIRST and LINK_LAST to kbuild this weekend and
reinstate the missing lines in drivers/usb/Makefile.  What I need from
the USB group is a documented (i.e. *why* is this order required)
definition of what needs to be linked first into usbdrv.o, and somebody
we can query if there are problems in the future.  It will probably be
as simple as

  # usb.o contains __init usb_init which must be executed before all
  # other usb __init routines, the 

Re: pcmcia in test10pre6

[Jonathan Hudson]

In article <[EMAIL PROTECTED]>,
"Jeff V. Merkey" <[EMAIL PROTECTED]> writes:

JVM> Grab the pcmcia off sourceforge.  It seems to build and work.  The stuff 
JVM> in 2.4 at present is still somewhat broken.  I worked on this until 2:00
JVM> last night getting it to build with 2.4.  

Couldn't get 3.1.21 to build (you using something later from CVS ?). [
CONFIG_X86_L1_CACHE_SHIFT not defined in the right places].

Droping the test5 modules/drivers into the pcmcia modules directory
works fine. 
-
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] kernel/module.c (plus gratuitous rant)

[Keith Owens]

On Fri, 27 Oct 2000 19:45:13 +0200, 
Pavel Machek <[EMAIL PROTECTED]> wrote:
>Would it be possible to keep 2.7.2.3? You still need 2.7.2.3 to
>reliably compile 2.0.X (and maybe even 2.2.all-but-latest?).

You can have multiple versions of gcc installed, just select the one to
use when you compile the kernel.

CC=gcc-2723 make 2.0 kernel
CC=gcc-2723 make 2.2 kernel
CC=egcs make 2.4 kernel

-
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's implementation of poll() not scalable?

[John Gardiner Myers]

Linus Torvolds wrote:
> So sticky arrays of events are good, while queues are bad. Let's take that 
> as one of the fundamentals.

Please let's not.  There is nothing fundamentally different between an
event queue of size N and an interest set of size N.

Your proposed interface suffers from most of the same problems as the
other Unix event interfaces I've seen.  Key among the problems are
inherent race conditions when the interface is used by multithreaded
applications.

The "stickiness" of the event binding can cause race conditions where
two threads simultaneously attempt to handle the same event.  For
example, consider a socket becomes writeable, delivering a writable
event to one of the multiple threads calling get_events().  While the
callback for that event is running, it writes to the socket, causing the
socket to become non-writable and then writeable again.  That in turn
can cause another writable event to be delivered to some other thread.

In the async I/O library I work with, this problem is addressed by
having delivery of the event atomically remove the binding.  If the
event needs to be bound after the callback is finished, then it is the
responsibility for the callback to rebind the event.  Typically, a
server implements a command/response protocol, where the read callback 
reads a command, writes the response, and repeats.  It is quite likely
that after the read callback completes, the connection is interested in
a write event, not another read event.

Cancellation of event bindings is another area prone to race
conditions.  A thread canceling an event binding frequently needs to
know whether or not that event has been delivered to some other thread. 
If it has, the canceling thread has to synchronize with the other thread
before destroying any resources associated with the event.

Multiple event queues are needed by libraries as different libraries can
have different thread pools.  The threads in those different pools can
have different characteristics, such as stack size, priority, CPU
affinity, signal state, etc.

There are three performance issues that need to be addressed by the
implementation of get_events().  One is that events preferably be given
to threads that are the same CPU as bound the event.  That allows the
event's context to remain in the CPU's cache.

Two is that of threads on a given CPU, events should wake threads in
LIFO order.  This allows excess worker threads to be paged out.

Three is that the event queue should limit the number of worker threads
contending with each other for CPU.  If an event is triggered while
there are enough worker threads in runnable state, it is better to wait
for one of those threads to block before delivering the event.
 S/MIME Cryptographic Signature

Re: kqueue microbenchmark results

[Dan Kegel]

Terry Lambert wrote:
> 
> > > Which is precisely why you need to know where in the chain of events this
> > > happened. Otherwise if I see
> > > 'read on fd 5'
> > > 'read on fd 5'
> > > How do I know which read is for which fd in the multithreaded case
> >
> > That can't happen, can it?  Let's say the following happens:
> >close(5)
> >accept() = 5
> >call kevent() and rebind fd 5
> > The 'close(5)' would remove the old fd 5 events.  Therefore,
> > any fd 5 events you see returned from kevent are for the new fd 5.
> 
> Strictly speaking, it can happen in two cases:
> 
> 1)  single acceptor thread, multiple worker threads
> 2)  multiple anonymous "work to do" threads
> 
> In both these cases, the incoming requests from a client are
> given to any thread, rather than a particular thread.
> 
> In the first case, we can have (id:executer order:event):
> 
> 1:1:open 5
> 2:2:read 5
> 3:4:read 5
> 2:3:close 5
> 
> If thread 2 processes the close event before thread 3 processes
> the read event, then when thread 3 attempts procssing, it will
> fail.

You're not talking about kqueue() / kevent() here, are you?
With that interface, thread 2 would not see a close event;
instead, the other events for fd 5 would vanish from the queue.
If you were indeed talking about kqueue() / kevent(), please flesh
out the example a bit more, showing who calls kevent().

(A race that *can* happen is fd 5 could be closed by another
thread after a 'read 5' event is pulled from the event queue and
before it is processed, but that could happen with any
readiness notification API at all.)

- Dan
-
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/

Tekram's TRM-1040S USCSI proc driver?

[Benson Chow]

Anyone know if Tekram's DC315/DC395 SCSI driver will be incorporated
into the kernel distribution?  I think their driver is GPL, or was there
some other reason it wasn't incorporated?

Their source code is on their website...

Just wonderring... (unfortunately I had a DC315 for a day but had to give
it up... it was the worst of the AHA2940A and DC390F that I already
had...)

-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: kqueue microbenchmark results

[Terry Lambert]

> > Which is precisely why you need to know where in the chain of events this
> > happened. Otherwise if I see
> > 
> > 'read on fd 5'
> > 'read on fd 5'
> > 
> > How do I know which read is for which fd in the multithreaded case
> 
> That can't happen, can it?  Let's say the following happens:
>close(5)
>accept() = 5
>call kevent() and rebind fd 5
> The 'close(5)' would remove the old fd 5 events.  Therefore,
> any fd 5 events you see returned from kevent are for the new fd 5.
> 
> (I suspect it helps that kevent() is both the only way to
> bind events and the only way to pick them up; makes it harder
> for one thread to sneak a new fd into the event list without
> the thread calling kevent() noticing.)

Strictly speaking, it can happen in two cases:

1)  single acceptor thread, multiple worker threads

2)  multiple anonymous "work to do" threads

In both these cases, the incoming requests from a client are
given to any thread, rather than a particular thread.

In the first case, we can have (id:executer order:event):

1:1:open 5
2:2:read 5
3:4:read 5
2:3:close 5

If thread 2 processes the close event before thread 3 processes
the read event, then when thread 3 attempts procssing, it will
fail.

Technically, this is a group ordering problem in the design of
the software, which should instead queue all events to a dispatch
thread, and the threads should use IPC to serialize processing of
serial events.  This is similar to the problem with async mounted
FS recovery in event of a crash: without ordering guarantees, you
can only get to a "good" state, not necessarily "the one correct
state".

In the second case, we can have:

1:2:read 5
2:1:open 5
3:4:read 5
2:3:close 5

This is just a non-degenerate form of the first case, where we
allow thread 1 and all other threads to be identical, and don't
serialize open state initialization.

The NetWare for UNIX system uses this model.  The benefit is
that all user space threads can be identical.  This means that
I can use either threads or processes, and it won't matter, so
my software can run on older systems that lack "perfect" threads
models, simply by using processes, and putting client state into
shared memory.

In this case, there is no need for inter-thread synchronization;
instead, we must insist that events be dispatched sequentially,
and that the events be processed serially.  This effectively
requires event processing completion notigfication from user
space to kernel space.

In NetWare for UNIX, this was accomplished using a streams MUX
which knew that the NetWare protocol was request-response.  This
also permitted "busy" responses to be turned around in kernel
space, without incurring a kernel-to-user space scheduling
penalty.  It also permitted "piggyback", where an ioctl to the
mux was used to respond, and combined sending a response with
the next read.  This reduced protection domain crossing and the
context switch overhead by 50%.  Finally, the MUX sent requests
to user space in LIFO order.  This approach is called "hot engine
scheduling", in that the last reader in from user space is the
most likely to have its pages in core, so as to not need swapping
to handle the next request.

I was architect of much of the process model discussed above; as
you can see, there are some significant performance wins to be
had by building the right interfaces, and putting the code on
the right side of the user/kernel boundary.

In any case, the answer is that you can not assume that the only
correct way to solve a problem like event inversion is serialization
of events in user space (or kernel space).  This is not strictly a
"threaded application implementation" issue, and it is not strictly
a kernel serialization of event delivery issue.

Another case, which NetWare did not handle, is that of rejected
authentication.  Even if you went with the first model, and forced
your programmers to use expensive inter-thread synchronization, or
worse, bound each client to a single thread in the server, thus
rendering the system likely to have skewed thread load, getting
worse the longer the connection was up, you would still have the
problem of rejected authentication.  A client might attempt to
send authentication followed by commands in the same packet series,
without waiting for an explicit ACK after each one (i.e. it might
attempt to implement a sliding window over a virtual circuit), and
the system on the other end might dilligently queue the events,
only to have the authentication be rejected, but with packets
queued already to user space for processing, assuming serialization
in user space.  You would then need a much more complex mechanism,
to allow you to invalidate an already queued event to another
thread, which you don't know about in your thread, before you
release the interlock.  Otherwise the client may get responses
without a valid authentication.

You need look no further than LDAPv3 for an example of a protocol
where this 

Re: [ANNOUNCE] ide-patch for 2.2.18(pre)

[Andre Hedrick]

Hi Bart,

The point is that I have stopped with the backport because of 2.4.0 push,
and I was waiting on you to pick it up again.

/pub/linux/kernel/people/hedrick/bkz/ide.2.2.18-17.all.20001027.patch.bz2

There you go Bart.

Cheers,

Andre Hedrick
The Linux ATA/IDE guy

-
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: Off-Topic (or maybe on-topic)

[Dr. Kelsey Hudson]

On Fri, 27 Oct 2000 [EMAIL PROTECTED] wrote:

> If Bill said 'screw you' to the blackmailer and made the press release,
> we should see the source on web sites soon.  Then we can see how bad it
> really is.  Maybe even fix it.

Why bother fixing it? It's too bloated and stupid in the first
place...That's why we run Linux.
Anyways, this is really causing too much clutter for this list.

 Kelsey Hudson   [EMAIL PROTECTED] 
 Software Engineer
 Compendium Technologies, Inc   (619) 725-0771
--- 

-
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: Bug in Linux VFAT filesystem: truncating file to greather size!]

[Ivan Baldo]

Hello.
I have sent this to the maintainer of the VFAT code some time ago and
it told me it doesn't have time.
It seems there is a bug and this bug still persists in 2.2.17 and
2.4.0-test9 (test9 says there is a bug on file.c line 69 and sometimes
on line 79 I think, I think this is the file.c of VFAT which has code
for reporting that bug on those lines).
Also note that there is a bug in kernel 2.4.0-test9 regarding to long
filenames on VFAT32 filesystems (it doesn't create them ok, test with
Scandisk or Norton Disk Doctor), you can easily check that.
Sorry this is somewhat vague, but I don't have much free time right
now, yet I will try to answer your questions or try to help you as much
as I can, so don't doubt to email me (I am not on the mailing list!).
I hope you can reproduce both of this bugs and fix them.
Thank you very much guys!

Here is the email I sent to the maintainer:

 Original Message 
From: Ivan Baldo <[EMAIL PROTECTED]>
Subject: Bug in Linux VFAT filesystem: truncating file to greather size!
To: [EMAIL PROTECTED]
CC: SET <[EMAIL PROTECTED]>, Gonzalo Piano <[EMAIL PROTECTED]>

Hello.
Please, if it is not you the correct person to email the bug, then
point me in the right direction and excuse me.
Do this:
- create a small C program that calls the "truncate()" function to
increase the size of an already existing file. Note that I am saying
*increase the size*, wich it is different from *truncating the file*.
Make sure the file is in a mounted VFAT filesystem and that both the
file and the increase in size are big (use 1mb for created file and
increase it to 2mb for example, or use greater  random values).
- unmount filesystem and check with your favourite program (I have
used Microsoft Scandisk and Norton Disk Doctor, I have not tryed
dosfsck...). Your checking program will say that the file has some sort
of bad allocation issues, etc. Don't worry, it does not seem to kill the
filesystem, only the file you created and tested.

Tested with home-compiled 2.2.15 Kernel, I have used GCC 2.95.2 and
binutils 2.9.5.0.22, most of the things are compiled statically (not as
modules), the filesystem things are all compiled statically. Another
friend tested with its 2.2.15 kernel, *and* another friend tested with
its 2.0.38 kernel!!! In all cases we have managed to reproduce the
problem! I have a little C program for doing this... it is in spanish
language but I think you will not need it... anyway, if you want this
program I can translate a bit of it (the code...) and send it to you.

I haven't researched which kernel doesn't has the bug, because I don't
have older kernels (disk space and cleaning issues and my internet
connection isn't very cheap) and because I have a big lack of free time.

I hope you can reproduce the problem and fix it easily.
If you want more information and maybe some more help (take in account
that I am not a very knowledgeable person... so I can do only easy
things...), then just email me! Maybe you want me to test a patch or
something...

Ok, thanks you so much! Bye.

P.s.: Netscape Messenger seems to rely on the ability to truncate a file
to a bigger size, but it uses it only for non important files (the
message files doesn't seem to have this problem, but the .summary files
do).
-- 
Ivan Baldo:
[EMAIL PROTECTED] - http://members.xoom.com/baldo - ICQ 10215364
Phone: (598) (2) 613 3223.
Caldas 1781, Malvin, Montevideo, Uruguay, South America.

(If you have problems with the previous addresses, try this ones:
[EMAIL PROTECTED], http://baldo.home.ml.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: test10-pre5 mount: Unable to handle kernel paging request at virtualaddress

[David Dyck]

On Wed, 25 Oct 2000, Brian Gerst wrote:

> > On Mon, 23 Oct 2000, David Dyck wrote:
> >
> > > I am getting a repeatable oops during the boot up phase,
> > > with linux 2.4.0  test10-pre4
>
> I know what your problem is now:
>
> > > Gnu C  2.7.2.3
>
> GCC 2.7.2.3 miscompiles the kernel_module structure.  Since this is
> where the exception table pointers are stored in a modular kernel, the
> page fault handler was failing to find the exception handler and causing
> an oops.

Thanks Brian,  I finally got around to updating the compiler,
and this did fix the problem

My thanks also to Barry for posting the patch to
Documentation/Changes

-
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/

linux-kernel people at Supercomputing 2000? (sc00)

[Erik Paulson]

Hello,
Sorry for the somewhat off-topic post, but I was wondering if anyone 
from l-k will be at Supercomputing next month (www.sc2000.org)

If so, would anyone be interested in having a BoF session? I'd be
particularly interested in knowing if any of the people working on big
iron machines are going to be there, and would maybe be interested
in making a short presentation.

If there's any interest, please respond to me off the list. I'll drop one
more note to linux-kernel if anything becomes of it, but otherwise this
will be the last message I subject most of you to.

Thanks!

-Erik
-
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] add __init to some IDE drivers

[Bartlomiej Zolnierkiewicz]

for 240t10p6, should be safe, please apply

--
Bartlomiej Zolnierkiewicz
<[EMAIL PROTECTED]>


diff -uNr linux-240t10p6/drivers/ide/alim15x3.c linux/drivers/ide/alim15x3.c
--- linux-240t10p6/drivers/ide/alim15x3.c   Thu Oct 19 22:05:01 2000
+++ linux/drivers/ide/alim15x3.cFri Oct 27 23:40:24 2000
@@ -691,7 +691,7 @@
}
 }
 
-void ide_dmacapable_ali15x3 (ide_hwif_t *hwif, unsigned long dmabase)
+void __init ide_dmacapable_ali15x3 (ide_hwif_t *hwif, unsigned long dmabase)
 {
if ((dmabase) && (m5229_revision < 0x20)) {
return;
diff -uNr linux-240t10p6/drivers/ide/amd7409.c linux/drivers/ide/amd7409.c
--- linux-240t10p6/drivers/ide/amd7409.cTue Oct  3 00:13:17 2000
+++ linux/drivers/ide/amd7409.c Fri Oct 27 23:40:50 2000
@@ -464,7 +464,7 @@
 #endif /* CONFIG_BLK_DEV_IDEDMA */
 }
 
-void ide_dmacapable_amd7409 (ide_hwif_t *hwif, unsigned long dmabase)
+void __init ide_dmacapable_amd7409 (ide_hwif_t *hwif, unsigned long dmabase)
 {
ide_setup_dma(hwif, dmabase, 8);
 }
diff -uNr linux-240t10p6/drivers/ide/hd.c linux/drivers/ide/hd.c
--- linux-240t10p6/drivers/ide/hd.c Tue Oct  3 00:14:24 2000
+++ linux/drivers/ide/hd.c  Fri Oct 27 23:55:58 2000
@@ -723,7 +723,7 @@
  * We enable interrupts in some of the routines after making sure it's
  * safe.
  */
-static void hd_geninit(void)
+static void __init hd_geninit(void)
 {
int drive;
 
diff -uNr linux-240t10p6/drivers/ide/hpt366.c linux/drivers/ide/hpt366.c
--- linux-240t10p6/drivers/ide/hpt366.c Tue Oct  3 00:16:08 2000
+++ linux/drivers/ide/hpt366.c  Fri Oct 27 23:40:29 2000
@@ -698,7 +698,7 @@
 #endif /* CONFIG_BLK_DEV_IDEDMA */
 }
 
-void ide_dmacapable_hpt366 (ide_hwif_t *hwif, unsigned long dmabase)
+void __init ide_dmacapable_hpt366 (ide_hwif_t *hwif, unsigned long dmabase)
 {
byte masterdma = 0, slavedma = 0;
byte dma_new = 0, dma_old = inb(dmabase+2);
diff -uNr linux-240t10p6/drivers/ide/icside.c linux/drivers/ide/icside.c
--- linux-240t10p6/drivers/ide/icside.c Tue Oct  3 14:27:31 2000
+++ linux/drivers/ide/icside.c  Fri Oct 27 23:53:40 2000
@@ -163,7 +163,7 @@
  * Purpose  : identify IDE interface type
  * Notes: checks the description string
  */
-static iftype_t icside_identifyif (struct expansion_card *ec)
+static iftype_t __init icside_identifyif (struct expansion_card *ec)
 {
unsigned int addr;
iftype_t iftype;
@@ -505,7 +505,7 @@
return hwif;
 }
 
-static int icside_register_v5(struct expansion_card *ec, int autodma)
+static int __init icside_register_v5(struct expansion_card *ec, int autodma)
 {
unsigned long slot_port;
ide_hwif_t *hwif;
@@ -527,7 +527,7 @@
return hwif ? 0 : -1;
 }
 
-static int icside_register_v6(struct expansion_card *ec, int autodma)
+static int __init icside_register_v6(struct expansion_card *ec, int autodma)
 {
unsigned long slot_port, port;
ide_hwif_t *hwif, *mate;
@@ -585,7 +585,7 @@
return hwif || mate ? 0 : -1;
 }
 
-int icside_init(void)
+int __init icside_init(void)
 {
int autodma = 0;
 
diff -uNr linux-240t10p6/drivers/ide/opti621.c linux/drivers/ide/opti621.c
--- linux-240t10p6/drivers/ide/opti621.cTue Jun 13 20:32:00 2000
+++ linux/drivers/ide/opti621.c Fri Oct 27 23:50:45 2000
@@ -308,7 +308,7 @@
 /*
  * ide_init_opti621() is called once for each hwif found at boot.
  */
-void ide_init_opti621 (ide_hwif_t *hwif)
+void __init ide_init_opti621 (ide_hwif_t *hwif)
 {
hwif->drives[0].drive_data = PIO_DONT_KNOW;
hwif->drives[1].drive_data = PIO_DONT_KNOW;
diff -uNr linux-240t10p6/drivers/ide/sl82c105.c linux/drivers/ide/sl82c105.c
--- linux-240t10p6/drivers/ide/sl82c105.c   Tue Jun 13 20:29:51 2000
+++ linux/drivers/ide/sl82c105.cFri Oct 27 23:43:24 2000
@@ -91,7 +91,7 @@
 }
 #endif
 
-void ide_dmacapable_sl82c105(ide_hwif_t *hwif, unsigned long dmabase)
+void __init ide_dmacapable_sl82c105(ide_hwif_t *hwif, unsigned long dmabase)
 {
unsigned char rev;
 
@@ -107,7 +107,7 @@
ide_setup_dma(hwif, dmabase, 8);
 }
 
-void ide_init_sl82c105(ide_hwif_t *hwif)
+void __init ide_init_sl82c105(ide_hwif_t *hwif)
 {
struct pci_dev *dev = hwif->pci_dev;
 
diff -uNr linux-240t10p6/drivers/ide/via82cxxx.c linux/drivers/ide/via82cxxx.c
--- linux-240t10p6/drivers/ide/via82cxxx.c  Fri Oct 27 16:34:53 2000
+++ linux/drivers/ide/via82cxxx.c   Fri Oct 27 23:41:01 2000
@@ -611,7 +611,7 @@
  * We allow the BM-DMA driver only work on enabled interfaces.
  */
 
-void ide_dmacapable_via82cxxx(ide_hwif_t *hwif, unsigned long dmabase)
+void __init ide_dmacapable_via82cxxx(ide_hwif_t *hwif, unsigned long dmabase)
 {
if ((via_enabled >> hwif->channel) & 1)
ide_setup_dma(hwif, dmabase, 8);

[ANNOUNCE] ide-patch for 2.2.18(pre)

[Bartlomiej Zolnierkiewicz]

I have ported ide-patch to 2.2.18-17 and I'm now backporting
2.4.0 changes. New VIA, SLC, OSB4 drivers and MANY other things
are already there.I hope that final 2.2.18-ide-patch will have
IDE functionality equal to this in 2.4.0-test10...

Here is a snapshot (it's not thoroughly audited and tested):
http://republika.pl/bkz/ide.2.2.18-17.all.20001027.patch.bz2

And please cut that bullshit about ide-patch 2.2.x being unmantained.
I don't use 2.2.x kernels anymore so I don't do ide-patches for pre
kernels. But there will be patches for stable 2.2.x. (Although it's
a real pain - I hate doing backporting instead of new stuff).

--
Bartlomiej Zolnierkiewicz
<[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: NCPFS flags all files executable on NetWare Volumes wit

[Jeff V. Merkey]

Petr Vandrovec wrote:
> 
>
> 
> In kernel fs/ncpfs/ncplib_kernel.c, there is function named
> ncp_del_file_or_subdir() which does:
> 
> #ifdef CONFIG_NCPFS_NFS_NS
>   if (server->name_space[volnum] == NW_NS_NFS)
>   {
> int result;
> 
> result = ncp_obtain_DOS_dir_base(server, volnum, dirent, name, );
> if (result) return result;
> return ncp_DeleteNSEntry(server, 1, volnum, dirent, NULL, NW_NS_DOS,
>htons(0x0680));

What wrong here is you have to read in each NS record (and the records
for the parent
file) and modify them.  You are just doing one and expecting the server
to do the work
of unlinking just the one.  You have to do each link yourself.  I will
fix.


>   }
>   else
> #endif
> return ncp_DeleteNSEntry(server, 1, volnum, dirent, name,
>server->name_space[volnum], htons(0x0680));
> 
> If you'll remove #ifdef-ed part, and you'll try to unlink some file
> using NFS namespace, server dies (on traditional filesystem, NSS works)
> with some internal inconsistency found error. Depending on search
> attributes (0x8006) passed to function, it either works only for directories
> (and abend for files), or works only for dirs (and refuses files), or
> does not work at all.
> 
>
> > You can expose these as .files the way HFS likes to see them, and MAC
> > clients to a Linux box
> > will be able to see and store their data in native MAC format -- with
> > finder info.
> 
> It is possible when using DOS or OS/2 namespace. But as NFS namespace
> allows all byte sequences up to 255 chars for filename (excluding chars
> 0, '/' and names "." and "..")...

I have code that translates MAC to DOS, DOS to NFS, NFS to MAC, etc.  
You have to convert the
names using the tables in NWFS, file NWCREATE.C.  There are tables I use
to generate the 
MAC names from an NFS name using these tables of valid and invalid
characters for each
namespace.  I have to do it for all the server Namespaces, since Netware
can cross mount 
NWFS volumes created under Linux.

Jeff

> Best regards,
> Petr Vandrovec
> [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/

[BUG] Another ext2 OOPS

[Udo A. Steinberg]

Hi,

I just got another oops with test10pre6. Decoded output follows.
Hopefully this helps to hunt a bug down.

-Udo


Unable to handle kernel NULL pointer dereference at virtual address 0010
c0130512
*pde = 
Oops: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax:    ebx: c13871cc   ecx: c38788c0   edx: c13871f8
esi: c13871cc   edi: 0001   ebp: cd9fad5c   esp: c9bc1ec8
ds: 0018   es: 0018   ss: 0018
Process bash (pid: 275, stackpage=c9bc1000)
Stack:  c13871cc 0001 cd9fad5c 0019 c02a cdae7480
cadc9680
   c9bc 0019  ca742000 c02d7180 0246 c01225d1

   c13871cc 0001 cd9fad5c 080e2902 c13871f4 01234567 c9bc
c13871f8

Call Trace: [] [] [] [] []
[] []
   []
Code: 8b 48 10 89 4c 24 40 c7 44 24 34 00 00 00 00 8b 5b 18 f6 c3

>>EIP; c0130512<=
Trace; c01225d1 <___wait_on_page+d1/e0>
Trace; c01505ff 
Trace; c014fee0 
Trace; c0122f2e 
Trace; c0123213 
Trace; c0123150 
Trace; c012ddfe 
Trace; c010a9d7 
Code;  c0130512 
 <_EIP>:
Code;  c0130512<=
   0:   8b 48 10  movl   0x10(%eax),%ecx   <=
Code;  c0130515 
   3:   89 4c 24 40   movl   %ecx,0x40(%esp,1)
Code;  c0130519 
   7:   c7 44 24 34 00 00 00  movl   $0x0,0x34(%esp,1)
Code;  c0130520 
   e:   00
Code;  c0130521 
   f:   8b 5b 18  movl   0x18(%ebx),%ebx
Code;  c0130524 
  12:   f6 c3 00  testb  $0x0,%bl
-
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/

Possible bounce messages...

[David Riley]

My mail server was messed up for a few days while I moved it and I'm not
sure if the bouncefilter caught all my bounce messages.  If it didn't,
I'm sorry.  Otherwise... well, forget it I guess.

Thanks,
David
-
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/

OOPS in nfsd, affects all 2.2 and 2.4 kernels

[Tony Lill]

This was first reported in 2.2.12, according to Deja. Solaris clients,
on rare occaisons, will send some command to a linux server which
causes a null resp->fh.fh_dentry to be passed to routines in
/usr/src/linux/fs/nfsd/nfsxdr.c. This causes an oops, and then the nfs
server subsystem stop functioning. A fix is to check that this is not
null before de-referencing it in the following three routines. I
looked and this bug is present in the latest 2.2 and 2.4 kernels.

Whatever condition causes this is very rare. We had a linux server
supporting 100 Solaris and HP-UX boxes running flawlessly for 8
months, then one day something triggered this bug, and it wouldn't go
away until I implemented this fix. There were no apparent side effects
to doing this, although you may want to print some informative message
to try and track down the real culprit.

THis patch is against 2.2.16, but the code looks unchanged in
2.4.0.

/usr/src/linux/fs/nfsd/nfsxdr.c Wed Nov 26 16:08:38 1997
--- nfsxdr.cWed Aug  9 19:07:40 2000
***
*** 364,370 
  nfssvc_encode_attrstat(struct svc_rqst *rqstp, u32 *p,
struct nfsd_attrstat *resp)
  {
!   if (!(p = encode_fattr(rqstp, p, resp->fh.fh_dentry->d_inode)))
return 0;
return xdr_ressize_check(rqstp, p);
  }
--- 364,371 
  nfssvc_encode_attrstat(struct svc_rqst *rqstp, u32 *p,
struct nfsd_attrstat *resp)
  {
!   if ( resp->fh.fh_dentry == NULL ||
!   !(p = encode_fattr(rqstp, p, resp->fh.fh_dentry->d_inode)))
return 0;
return xdr_ressize_check(rqstp, p);
  }
***
*** 373,379 
  nfssvc_encode_diropres(struct svc_rqst *rqstp, u32 *p,
struct nfsd_diropres *resp)
  {
!   if (!(p = encode_fh(p, >fh))
 || !(p = encode_fattr(rqstp, p, resp->fh.fh_dentry->d_inode)))
return 0;
return xdr_ressize_check(rqstp, p);
--- 374,381 
  nfssvc_encode_diropres(struct svc_rqst *rqstp, u32 *p,
struct nfsd_diropres *resp)
  {
!   if ( resp->fh.fh_dentry == NULL ||
!   !(p = encode_fh(p, >fh))
 || !(p = encode_fattr(rqstp, p, resp->fh.fh_dentry->d_inode)))
return 0;
return xdr_ressize_check(rqstp, p);
***
*** 392,398 
  nfssvc_encode_readres(struct svc_rqst *rqstp, u32 *p,
struct nfsd_readres *resp)
  {
!   if (!(p = encode_fattr(rqstp, p, resp->fh.fh_dentry->d_inode)))
return 0;
*p++ = htonl(resp->count);
p += XDR_QUADLEN(resp->count);
--- 394,401 
  nfssvc_encode_readres(struct svc_rqst *rqstp, u32 *p,
struct nfsd_readres *resp)
  {
!   if ( resp->fh.fh_dentry == NULL ||
!   !(p = encode_fattr(rqstp, p, resp->fh.fh_dentry->d_inode)))
return 0;
*p++ = htonl(resp->count);
p += XDR_QUADLEN(resp->count);


--
Tony Lill, [EMAIL PROTECTED]
President, A. J. Lill Consultantsfax/data (519) 650 3571
539 Grand Valley Dr., Cambridge, Ont. N3H 2S2 (519) 241 2461
--- http://www.ajlc.waterloo.on.ca/ 
"Welcome to All Things UNIX, where if it's not UNIX, it's CRAP!"
-
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: NCPFS flags all files executable on NetWare Volumes wit

[Petr Vandrovec]

On 27 Oct 00 at 15:14, Jeff V. Merkey wrote:
> Petr Vandrovec wrote:
> > 
> > On 27 Oct 00 at 13:46, Jeff V. Merkey wrote:
> > > Here's the complete set of 3.x/4.x/5.x Namespace NCP calls with proper
> > > return codes.  I'll run down the huge-data info and post a bit later.
> > 
> > Thanks. Main problem with hardlinks is that unlink through NFS namespace
> > kills server (at least up to 5.0, I did not checked it during last few
> > months), and unlink through DOS (or OS2) namespace removes all instances
> > of hardlinked file :-( A bit unfortunate behavior.
> 
> Where are you doing this in the code?  I'll go look at it and attempt a
> fix.  It's killing the server because the linkage fields are probably
> not getting set.  If NFSSERV is loaded, and the

In kernel fs/ncpfs/ncplib_kernel.c, there is function named 
ncp_del_file_or_subdir() which does:

#ifdef CONFIG_NCPFS_NFS_NS
  if (server->name_space[volnum] == NW_NS_NFS)
  {
int result;

result = ncp_obtain_DOS_dir_base(server, volnum, dirent, name, );
if (result) return result;
return ncp_DeleteNSEntry(server, 1, volnum, dirent, NULL, NW_NS_DOS,
   htons(0x0680));
  }
  else
#endif
return ncp_DeleteNSEntry(server, 1, volnum, dirent, name, 
   server->name_space[volnum], htons(0x0680));

If you'll remove #ifdef-ed part, and you'll try to unlink some file
using NFS namespace, server dies (on traditional filesystem, NSS works)
with some internal inconsistency found error. Depending on search
attributes (0x8006) passed to function, it either works only for directories
(and abend for files), or works only for dirs (and refuses files), or
does not work at all.
  
> links ever get hosed, you will get an Abend on 3.x and 4.x, and a
> "process suspended" error on 5.x (which also hangs the server).  If the

It is always without any modifications through NFS namespace info, as
I'm not using it at all.

> also because these linkage fields are not getting set properly.  It does
> not work this way 
> with the NetWare NFSSERV.NLM mounted as an NFS client from Linux.

NUC interface is also OK (as unixware happily uses that), only NCP 87,8
is broken. I did not ever tried to unlink file if NFSSERV is loaded...
 
> > > /6804   Return Bindery Context (you need to implement this one
> > > -- I did not see it in your code)
> > 
> > ncpfs 2.2.0.18 implements this (lib/ds/bindctx.c:NWDSGetBinderyContext),
> > but does not use it itself...
> 
> It should.  It will allow you to use NDS with your existing code and NCP
> suite.  I guess 
> doug's next project at TRG will be to put in NDS support in NCPFS and
> submit the patches to you.

ncpfs (2.2.0.18/2.2.0.19pre) supports almost complete documented NWDS* 
set of functions. Only thing missing are ACL assigning code, you must
do it yourself through NWDSModifyObject calls.

> > Userspace ncpfs (specifically ncopy) uses
> > (lib/filemgmt.c:ncp_ns_open_create_entry) NCP 87,30 or 87,33 for this
> > (and NW3.x is out of luck, AFAIK). Kernel code does not support MAC
> > forks (and ACL and extended attributes), as up to now there is no
> > vfs API for this... You have to use ncopy,nwdir/nwrights,
> > nwtrustee,...,nwdir/eaops,nwdir for accessing MAC()/ACL/EAs for now.
> > (for EAs you must have post-August 27 ncpfs, betas are on
> > ftp://platan.vc.cvut.cz/private/ncpfs)
> 
> You can expose these as .files the way HFS likes to see them, and MAC
> clients to a Linux box 
> will be able to see and store their data in native MAC format -- with
> finder info.

It is possible when using DOS or OS/2 namespace. But as NFS namespace 
allows all byte sequences up to 255 chars for filename (excluding chars
0, '/' and names "." and "..")...
Best regards,
Petr Vandrovec
[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: mkraid

[Igmar Palsenberg]

On Fri, 27 Oct 2000, [iso-8859-1] Jakob Østergaard wrote:

> On Fri, Oct 27, 2000 at 10:56:16AM -0700, Anil kumar wrote:
> > Hi,
> >   
> >  I have a problem with mkraid 
> 
> This is Linux-RAID specific and not material for the linux-kernel
> list.
> 
> Please, just post your questions to linux-raid, not linux-kernel.
> 
> And most importantly, when you ask me these exact same questions in direct
> e-mail anyway, it is a little wasteful to also trouble this list with your
> question as well.
> 
> Thank you,
>  (and you got the answer in the reply to the direct mail two minutes ago)

He isn't reading the docs.. 

I agree that making RAID fully work (including RAID'ed root-fs) takes some
nicely hacking, but not that can be done without docs.

I did it, so can anyone else


Igmar


-
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: Big file support in Linux 2.2

[Igmar Palsenberg]

> Hello,
> 
> For one of our projects here, we've crashed head first into the 2 gig file size
> limitation in Linux 2.2 kernels. While I know that this has been solved in
> 2.3/2.4, has there been any work to backport this feature into a Linux 2.2
> kernel? I'm looking for a temporary solution until we can move to Linux 2.4
> directly, but obviously not until after it's been "really" released. :)
> 
> Yes, I know this is likely to be relatively unstable. (Probably almost as
> unstable as running a 2.4-pre kernel in production), but at least it would give
> us a start.

Seek for LFS on Freshmeat. Requires a kernel patch, and a glibc
recompile. I'm still having some problems with it, mainly cp -ar giving
some wonderful weard strace results.

> 
> Thanks for your help,
> 
> Joe


Igmar

-
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: pcmcia in test10pre6

[David Ford]

"Jeff V. Merkey" wrote:

> Grab the pcmcia off sourceforge.  It seems to build and work.  The stuff
> in 2.4 at present is still somewhat broken.  I worked on this until 2:00
> last night getting it to build with 2.4.  Thanks to Alan for pointing
> me to a package that actually works and will build on 2.4.

Yes and no, pulling a modem/lan card out of my machine still causes an instant 
hardware lockup.  You have put a lot of work into it that I greatly
appreciate, but the 2.4 PCMCIA is still a festering wound for some of the hardware I 
have.  I'm not whining here, I know it'll take time to get things
working and I have one of the most problematic pieces of hardware in regards to 2.4 
PCMCIA.

-d

--
  "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: NCPFS flags all files executable on NetWare Volumes wit

[Jeff V. Merkey]

Petr Vandrovec wrote:
> 
> On 27 Oct 00 at 13:46, Jeff V. Merkey wrote:
> > Here's the complete set of 3.x/4.x/5.x Namespace NCP calls with proper
> > return codes.  I'll run down the huge-data info and post a bit later.
> 
> Thanks. Main problem with hardlinks is that unlink through NFS namespace
> kills server (at least up to 5.0, I did not checked it during last few
> months), and unlink through DOS (or OS2) namespace removes all instances
> of hardlinked file :-( A bit unfortunate behavior.

Where are you doing this in the code?  I'll go look at it and attempt a
fix.  It's killing the server because the linkage fields are probably
not getting set.  If NFSSERV is loaded, and the
links ever get hosed, you will get an Abend on 3.x and 4.x, and a
"process suspended" error on 5.x (which also hangs the server).  If the
wrong pipe of fifo octals get set in mode,
it will also hang the server.  If it is removing the entire namespace
with hardlinks, it's 
also because these linkage fields are not getting set properly.  It does
not work this way 
with the NetWare NFSSERV.NLM mounted as an NFS client from Linux.

> 
> > let me know.  I have a 600 page document I wrote two years ago that
> > details every single NCP and NDS NCP used,
> > and can send it to you via UPS in .cz.   It's too big to fax, or post.
> 
> Not for now.


> 
> > /6804   Return Bindery Context (you need to implement this one
> > -- I did not see it in your code)
> 
> ncpfs 2.2.0.18 implements this (lib/ds/bindctx.c:NWDSGetBinderyContext),
> but does not use it itself...

It should.  It will allow you to use NDS with your existing code and NCP
suite.  I guess 
doug's next project at TRG will be to put in NDS support in NCPFS and
submit the patches to you.

> 
> > /6805   Monitor NDS Connection (this one will allow you to
> > intercept NDS replica packets and suck an NDS replica local)
> 
> Novell documentation is a bit - hmm - unclear on this one...

There's some undocumented diagnostic calls in NDS that basically render
it totally unsuitable for the internet and make it easy to hack.  It's
great for LANs in an organization where the
servers can all be locked up, and employees can get fired for hacking. 
On the internet, it's
a piece of "swiss cheese" and is vulnerable in many respects.

> 
> > /1631   Open Data Stream (this NCP will allow you to open the
> > MAC namespace data fork and read it remotely for MAC clients)
> 
> Userspace ncpfs (specifically ncopy) uses
> (lib/filemgmt.c:ncp_ns_open_create_entry) NCP 87,30 or 87,33 for this
> (and NW3.x is out of luck, AFAIK). Kernel code does not support MAC
> forks (and ACL and extended attributes), as up to now there is no
> vfs API for this... You have to use ncopy,nwdir/nwrights,
> nwtrustee,...,nwdir/eaops,nwdir for accessing MAC()/ACL/EAs for now.
> (for EAs you must have post-August 27 ncpfs, betas are on
> ftp://platan.vc.cvut.cz/private/ncpfs)


You can expose these as .files the way HFS likes to see them, and MAC
clients to a Linux box 
will be able to see and store their data in native MAC format -- with
finder info.

Jeff

> Thanks,
> Petr Vandrovec
> [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/
-
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] cpu detection fixes for test10-pre4

[H. Peter Anvin]

Alan Cox wrote:
> 
> > > True enough, personally I prefer "x86".
> >
> > ia32 is the official name. OTOH, i[3-6]86 _are_ different beasts...
> 
> ia32 is an intel trademark. Using it for non intel products is probably an
> actionable matter ..
> 

Yet another reason to ignore it.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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] kernel/module.c (plus gratuitous rant)

[Alan Cox]

> Pavel Machek wrote:
> > Would it be possible to keep 2.7.2.3? You still need 2.7.2.3 to
> > reliably compile 2.0.X (and maybe even 2.2.all-but-latest?).
> 
> What fails, when you use egcs-1.1.2 to build 2.0.x or early 2.2.x?

egcs miscompiles inlined strstr. It gets combined with bad asm constraints
to mean that 2.0 and earlier 2.2 will crash when fed the right (wrong ?) 
sequence of FPU ops to software emulate


-
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: GPL Question

[Brian F. G. Bidulock]

All, IANAL, but:

#1: take this discussion of this list...

goto news:comp.software.licensing

read the FAQ

if you still have questions send them to mailto:[EMAIL PROTECTED]

if you don't like any of those answers, talk to a lawyer

be fair, don't steal someone else's work (don't be like Dennis)

both GPL and LGPL are clear: you change it, you publish source

if you don't want to publish source, best bet is don't change it,
just use it the way it is

you may not have the right to change anything (according to your
employer): consult a lawyer

--Brian

On Fri, 27 Oct 2000, James Sutherland wrote:

> On Fri, 27 Oct 2000, David Schwartz wrote:
> 
> > 
> > > Now, if a module is loaded that registers a set of functions that have
> > > increased functionality compared to the original functions, if that
> > > modules is not based off GPL'd code, must the source code of that module
> > > be released under the GPL?
> > 
> > If the answer to this is "yes", then Microsoft should own some rights to
> > every piece of software that uses the Windows API.
> 
> In fact, since you call the Windows API by linking against Windows
> libraries (kernel32.dll etc), Microsoft have as much right to dictate the
> licensing of Windows apps as the FSF has to require apps linked against
> GPLed code to be GPLed. (IMO, neither has any such right; of course, given
> the spate of recent laws we've seen, I wouldn't put any faith in a legal
> system to reach the "right" decision...)
> 
> In this particular case - just communicating with GPLed code - the answer
> is no, you are not required to impose GPL restrictions on your users, you
> can use a free license instead (or a proprietary one, if you really
> want...)
> 
> 
> James.
> 
> -
> 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/

-- 
Brian F. G. Bidulock
http://www.openss7.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: syslog() blocks on glibc 2.1.3 with kernel 2.2.x

[Igmar Palsenberg]

> Sadly, you WILL still lose entries if the system crashes before fs metadata
> has been flushed to disk.  Unless the inode has the correct size stored, the
> crap fsync()ed to disk doesn't make much difference.

Yep. I can't really think of a case where you wouldn't lose data in case
of for example a hard lock.

> (This is amplified by dcache.)

I'm not that familiar with kernel internals..

To bring up that point : Anyone had a good advice on a good OS internals
book ?? I'm gonna read the 2.2.x kernel sources, so I could use a good
background.


Regards,

Igmar

-
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: syslog() blocks on glibc 2.1.3 with kernel 2.2.x

[Igmar Palsenberg]

> This is not an option for us, unfortunately.  Many of our IP addresses
> are dynamically assigned, with the DNS tables dynamically updated.

Not an option in that case.
 
> Thank you for the patch to syslogd, though!  Can you try to get your
> "-x" option into the standard distributions of syslogd, or should I
> work up a bug report / feature request for Red Hat myself?

I have no idea who officially maintains it.. putting a bug report with RH
should be a good idea. The patch is untested, so someone needs to verify
that remote logging indeed nog is IP only. 

>  - Pat
> 


Igmar

-
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 Printer, in 2.4.0-test9

[Randy Dunlap]

Gerald, Benson-

USB in 2.4.0-test9 had several broken pieces in it.
Something like 2.4.0-test10-pre6 is much better IMO.
However, the USB printer driver in test10-pre6 still
needs the attached patch (already sent to Linus).

Please try test10-pre6 with this patch and let me know how it is.

Thanks,
~Randy


[EMAIL PROTECTED] wrote:
> 
> In article
>  <[EMAIL PROTECTED]>,
> Benson Chow <[EMAIL PROTECTED]> wrote:
> 
> > I get a bunch of form feeds too but it continues to print a few
> > characters fine and some that are totally wrong.
> 
> The same problem here. I'am using a dual Pentium (GA586-DX) with 2 x 233
> MHz PentiumMMX and a PCI USB controller card with a VIA Chip. The
> printer is
> a DeskJet 970Cxi. Printing via USB is completely impossible.
> 
>  Gerald

--- linux/drivers/usb/printer.c.org Thu Oct 26 17:36:50 2000
+++ linux/drivers/usb/printer.c Thu Oct 26 17:09:53 2000
@@ -190,6 +190,8 @@
retval = retval > 1 ? -EIO : -ENOSPC;
goto out;
}
+#else
+   retval = 0; 
 #endif
 
usblp->used = 1;
@@ -383,6 +385,7 @@
return -EFAULT;
 
if ((usblp->readcount += count) == usblp->readurb.actual_length) {
+   usblp->readcount = 0;
usblp->readurb.dev = usblp->dev;
usb_submit_urb(>readurb);
}

Re: Somewhat different GPL Question

[Alan Cox]

> If you're making interprocess calls to call the GPL code,
> I suspect you won't have to make your code GPL.
> 
> OTOH, if you /link/ against a GPL shared library, you will
> have to GPL the source of your program (that is, you'll have
> to give it to the people who receive the binary from you).

The out of court settlements don't actually bear up to this interpretation
and have been more about 'depending on' as a definition for linking and what
is and is not an entire application.

Its one reason Im glad Linus had the sense to put an explicit statement about
syscalls in the kernel COPYING file.

-
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: Not reproducable crc error at boot :-(

[Anton Altaparmakov]

Hi,

I would suggest to increase the 8bit waitstates in the BIOS by +1 (or
more). - you might have to increase the 16bit waitstates as well (or
instead of the 8bit ones).

It cured such a problem for me: - A Intel Pentium PC that had run Netware
3.12 perfectly happily for years didn't boot up with a CRC error after
installing RedHat 7.0 on it. - Increasing the 8bit waitstates from 1 to 2
cured the problem completely and the PC is rocksolid now. - The PC also
ran Windows quite happily (I installed it after the trouble with Linux
just to see if it would work - I was worried about the hardware having
gone dodgy.)

Hope this helps.

Regards,

Anton

On Fri, 27 Oct 2000, Remi Turk wrote:

> Hi folks,
> when booting pre5 I got a crc-error while uncompressing
> the kernel this morning. (/usr/src/linux/lib/inflate.c:1166 AFAICS)
> Rebooting didn't trigger it again and it's the first time I ever saw it.
> 
> I've never had any SIG11 problems while compiling kernels so I wouldn't
> expect bad RAM. (Normal people probably run Seti@home,
> I run "while make bzImage; do date >> /tmp/kcompile; make clean; done"
> ;-)
> 
> OTOH, it's not reproducable which seems an indicator for hardware
> trouble :-(
> 
> Does anybody have any ideas?
> 
> Linux version 2.4.0-test10-pre5 ([EMAIL PROTECTED])
> (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release))
> #1 Tue Oct 24 17:14:24 CEST 2000
> 
> processor : 0
> vendor_id : AuthenticAMD
> cpu family: 5
> model : 8
> model name: AMD-K6(tm) 3D processor
> stepping  : 0
> cpu MHz   : 350.000809
> cache size: 64 KB
> fdiv_bug  : no
> hlt_bug   : no
> sep_bug   : no
> f00f_bug  : no
> coma_bug  : no
> fpu   : yes
> fpu_exception : yes
> cpuid level   : 1
> wp: yes
> flags : fpu vme de pse tsc msr mce cx8 sep mmx 3dnow
> bogomips  : 699.60
> 
> -- 
> Linux 2.4.0-test10-pre5 #1 Tue Oct 24 17:14:24 CEST 2000
> -
> 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/
> 


-- 

Anton Altaparmakov   Phone: +44-(0)1223-333541 (lab)
Christ's College eMail: [EMAIL PROTECTED]
Cambridge CB2 3BU  WWW: http://www-stu.christs.cam.ac.uk/~aia21/
United Kingdom ICQ: 8561279

-
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] cpu detection fixes for test10-pre4

[Alan Cox]

> > True enough, personally I prefer "x86".
> 
> ia32 is the official name. OTOH, i[3-6]86 _are_ different beasts...

ia32 is an intel trademark. Using it for non intel products is probably an
actionable matter ..

-
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: GPL Question

[Alan Cox]

> >  If the answer to this is "yes", then Microsoft should own
> > some rights to every piece of software that uses the Windows
> > API.
> 
> Read the fine print...
> *runs like crazy*

Extremely true. You'll find the MS C library covers this in detail. You'll also
famously find the microsoft sdk for generating paperclip like horrors actually
forbids you using it for the purpose of making things derogatory to MS etc

-
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: GPL Question

[Alan Cox]

>   If the answer to this is "yes", then Microsoft should own some rights to
> every piece of software that uses the Windows API.

As US copyright law stands of the last few days Microsoft are entitled to 
require a magic constant is passed in one register to 'unlock' an API syscall.
If you disassemble code to find that constant you could be jailed.

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: [patch] kernel/module.c (plus gratuitous rant)

[Alan Cox]

> Would it be possible to keep 2.7.2.3? You still need 2.7.2.3 to
> reliably compile 2.0.X (and maybe even 2.2.all-but-latest?).

There has only been one know egcs 1.1 build problem found in the last 9 
months or so (the fpu emu one). I really dont think using egcs 1.1.2 to build
2.2 kernels is a problem. In fact its probably the default nowdays

-
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/

Not reproducable crc error at boot :-(

[Remi Turk]

Hi folks,
when booting pre5 I got a crc-error while uncompressing
the kernel this morning. (/usr/src/linux/lib/inflate.c:1166 AFAICS)
Rebooting didn't trigger it again and it's the first time I ever saw it.

I've never had any SIG11 problems while compiling kernels so I wouldn't
expect bad RAM. (Normal people probably run Seti@home,
I run "while make bzImage; do date >> /tmp/kcompile; make clean; done"
;-)

OTOH, it's not reproducable which seems an indicator for hardware
trouble :-(

Does anybody have any ideas?

Linux version 2.4.0-test10-pre5 ([EMAIL PROTECTED])
(gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release))
#1 Tue Oct 24 17:14:24 CEST 2000

processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 5
model   : 8
model name  : AMD-K6(tm) 3D processor
stepping: 0
cpu MHz : 350.000809
cache size  : 64 KB
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr mce cx8 sep mmx 3dnow
bogomips: 699.60

-- 
Linux 2.4.0-test10-pre5 #1 Tue Oct 24 17:14:24 CEST 2000
-
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: Blocked processes <=> Elevator starvation?

[Jens Axboe]

On Fri, Oct 27 2000, Rui Sousa wrote:
> I finally had time to give this a better look. It now seems the problem
> is in the VM system.
> 
> I patched a test10-pre4 kernel with kdb, then started two "diff -ur
> linux-2.4.0testX linux-2.4.0testY > log1" and two "find / -true >
> log". After this I tried cat"ing" a small file. The cat never 
> returned. At this point I entered kdb and did a stack trace on the "cat"
> process:
> 
> schedule()
> ___wait_on_page()
> do_generic_file_read()
> generic_file_read()
> sys_read()
> system_call()
> 
> So it seems the process is either in a loop in ___wait_on_page()
> racing for the PageLock or it never wakes-up... (I guess I could add a
> printk to check which)
> Unfortunately I didn't find anything obviously wrong with the code.
> I hope you can do a better job tracking the problem down.

Rik is right, just because you are seeing long waits on wait_on_page
doesn't make it a vm problem. When a I/O on a page completes, the
page will be unlocked and wait_on_page can grab it -- so I/O stalls
would results in this behaviour.

Could you try this patch:

*.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.0-test10-pre6/blk-7.bz2

and see if it makes a difference?

-- 
* 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/

Re: [patch] kernel/module.c (plus gratuitous rant)

[Jeff Garzik]

Pavel Machek wrote:
> Would it be possible to keep 2.7.2.3? You still need 2.7.2.3 to
> reliably compile 2.0.X (and maybe even 2.2.all-but-latest?).

What fails, when you use egcs-1.1.2 to build 2.0.x or early 2.2.x?

Maybe they need -fno-strict-aliasing... is that what you are referring
to?

Regards,

Jeff



-- 
Jeff Garzik| "Mind if I drive?"  -Sam
Building 1024  | "Not if you don't mind me clawing at
the
MandrakeSoft   |  dash and screaming like a
cheerleader."
   |  -Max
-
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: Question: multiple major numbers - one driver

[Andreas Dilger]

Chris Parker writes:
> I have a need for more than 256 minor numbers.  I could add some 
> more major numbers, thus getting the number of majors * 256.
> I would like to have only device driver loaded to handle the
> multiple majors.

Look at the SCSI/IDE/COMPAQ Smart RAID/etc drivers that have multiple
major numbers registered (per Documentation/devices.txt).  Some of
the storage drivers have been allocating blocks of 8 major numbers at
a time.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [patch] kernel/module.c (plus gratuitous rant)

[Pavel Machek]

Hi!

> > if the person who sent you the -pre4 patch against module.c
> > had Cc:'ed this mailing list then your kernel would do
> > something useful when compiled with gcc-2.7.2.3.
> 
> It seems that gcc-2.7.2.3 is terminally ill. I'd rather change
> Documentation/Changes, and just document the fact.
> 
> These kinds of subtle work-arounds for gcc bugs are not really acceptable,
> nor is it worthwhile complaining when somebody does development with a gcc
> that is _not_ broken, and doesn't notice that some random gcc bug breaks
> the kernel for others.

Would it be possible to keep 2.7.2.3? You still need 2.7.2.3 to
reliably compile 2.0.X (and maybe even 2.2.all-but-latest?).
Pavel
-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [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: NCPFS flags all files executable on NetWare Volumes wit

[Petr Vandrovec]

On 27 Oct 00 at 13:46, Jeff V. Merkey wrote:
> Here's the complete set of 3.x/4.x/5.x Namespace NCP calls with proper
> return codes.  I'll run down the huge-data info and post a bit later.

Thanks. Main problem with hardlinks is that unlink through NFS namespace
kills server (at least up to 5.0, I did not checked it during last few
months), and unlink through DOS (or OS2) namespace removes all instances 
of hardlinked file :-( A bit unfortunate behavior.
 
> let me know.  I have a 600 page document I wrote two years ago that
> details every single NCP and NDS NCP used,
> and can send it to you via UPS in .cz.   It's too big to fax, or post.

Not for now.

> /6804   Return Bindery Context (you need to implement this one
> -- I did not see it in your code)

ncpfs 2.2.0.18 implements this (lib/ds/bindctx.c:NWDSGetBinderyContext),
but does not use it itself...

> /6805   Monitor NDS Connection (this one will allow you to
> intercept NDS replica packets and suck an NDS replica local)

Novell documentation is a bit - hmm - unclear on this one...
 
> /1631   Open Data Stream (this NCP will allow you to open the
> MAC namespace data fork and read it remotely for MAC clients)

Userspace ncpfs (specifically ncopy) uses 
(lib/filemgmt.c:ncp_ns_open_create_entry) NCP 87,30 or 87,33 for this
(and NW3.x is out of luck, AFAIK). Kernel code does not support MAC
forks (and ACL and extended attributes), as up to now there is no 
vfs API for this... You have to use ncopy,nwdir/nwrights,
nwtrustee,...,nwdir/eaops,nwdir for accessing MAC()/ACL/EAs for now.
(for EAs you must have post-August 27 ncpfs, betas are on
ftp://platan.vc.cvut.cz/private/ncpfs)
Thanks,
Petr Vandrovec
[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/

[PATCH] kiobuf/rawio fixes for 2.4.0-test10-pre6

[Christoph Hellwig]

Ok, forgot to Cc linux-kernel ...
Please Cc linus on reply.

- Forwarded message from Christoph Hellwig <[EMAIL PROTECTED]> -

Date: Fri, 27 Oct 2000 22:03:54 +0200
From: Christoph Hellwig <[EMAIL PROTECTED]>
To: Linus Torvalds <[EMAIL PROTECTED]>
Subject: [PATCH] kiobuf/rawio fixes for 2.4.0-test10-pre6
X-Mailer: Mutt 1.0i

Hi Linus,

Stephen Tweedies last kiobuf patchset contained a lot bu fixes
besides new features. These bug-fixes are not yet merged in 2.4.0.

This patch contains forward-ports of the follwoing fixes
(quote from his 00README):

01-mapfix.diff

map_user_kiobuf() retries failed maps to cover a race in which
the swapper steals a page before the kiobuf has grabbed and
locked it.

02-iocount.diff

Kanoj Sarcar's fixes to allow kiobufs to work properly over
fork(), even on threaded applications.

04-eiofix.diff

Fix to return -EIO instead of 0 if a raw I/O read or write
encounters an error in the first block.

06-enxio.diff
Return ENXIO on read/write at or beyond the end of the device
for raw I/O

Please apply.

Christoph

-- 
Always remember that you are unique.  Just like everyone else.


diff -uNr --exclude-from=dontdiff linux.orig/drivers/char/raw.c 
linux/drivers/char/raw.c
--- linux.orig/drivers/char/raw.c   Thu Oct 19 13:21:24 2000
+++ linux/drivers/char/raw.cTue Oct 24 13:25:47 2000
@@ -277,8 +277,11 @@

if ((*offp & sector_mask) || (size & sector_mask))
return -EINVAL;
-   if ((*offp >> sector_bits) > limit)
+   if ((*offp >> sector_bits) > limit) {
+   if (size)
+   return -ENXIO;
return 0;
+   }
 
/* 
 * We'll just use one kiobuf
diff -uNr --exclude-from=dontdiff linux.orig/fs/buffer.c linux/fs/buffer.c
--- linux.orig/fs/buffer.c  Tue Oct 24 13:15:49 2000
+++ linux/fs/buffer.c   Tue Oct 24 13:26:31 2000
@@ -1924,6 +1924,8 @@

spin_unlock(_list_lock);
 
+   if (!iosize)
+   return -EIO;
return iosize;
 }
 
diff -uNr --exclude-from=dontdiff linux.orig/include/linux/mm.h 
linux/include/linux/mm.h
--- linux.orig/include/linux/mm.h   Tue Oct 24 13:15:56 2000
+++ linux/include/linux/mm.hTue Oct 24 14:41:46 2000
@@ -157,8 +157,9 @@
wait_queue_head_t wait;
struct page **pprev_hash;
struct buffer_head * buffers;
-   void *virtual; /* non-NULL if kmapped */
+   void *virtual;  /* non-NULL if kmapped */
struct zone_struct *zone;
+   atomic_t rawcount;  /* count of raw io in progress */
 } mem_map_t;
 
 #define get_page(p)atomic_inc(&(p)->count)
diff -uNr --exclude-from=dontdiff linux.orig/mm/memory.c linux/mm/memory.c
--- linux.orig/mm/memory.c  Tue Oct 24 13:15:58 2000
+++ linux/mm/memory.c   Tue Oct 24 16:09:22 2000
@@ -138,6 +138,30 @@
check_pgt_cache();
 }
 
+/*
+ * Establish a new mapping:
+ *  - flush the old one
+ *  - update the page tables
+ *  - inform the TLB about the new one
+ */
+static inline void establish_pte(struct vm_area_struct * vma, unsigned long address,
+   pte_t *page_table, pte_t entry)
+{
+   flush_tlb_page(vma, address);
+   set_pte(page_table, entry);
+   update_mmu_cache(vma, address, entry);
+}
+
+static inline void break_cow(struct vm_area_struct * vma, struct page *
+old_page,
+   struct page * new_page, unsigned long address, 
+   pte_t *page_table)
+{
+   copy_cow_page(old_page,new_page,address);
+   flush_page_to_ram(new_page);
+   flush_cache_page(vma, address);
+   establish_pte(vma, address, page_table, 
+pte_mkwrite(pte_mkdirty(mk_pte(new_page, vma->vm_page_prot;
+}
+
 #define PTE_TABLE_MASK ((PTRS_PER_PTE-1) * sizeof(pte_t))
 #define PMD_TABLE_MASK ((PTRS_PER_PMD-1) * sizeof(pmd_t))
 
@@ -227,6 +251,22 @@
 
/* If it's a COW mapping, write protect it both in the 
parent and the child */
if (cow) {
+   /* Rawio in progress? */
+   if (atomic_read(>rawcount)) {
+   /*
+* If pte is dirty, its a private page,
+* rawio was initiated by a clone.
+* For dmain operation, need to break
+* cow.
+*/
+   if (pte_dirty(pte)) {
+   struct page * new_page = 
+alloc_page(GFP_HIGHUSER);
+   if (!new_page)
+   goto 

netscape and 2.2.18pre1[67] alpha

[Ulrich Kiermayr]

Hello!

I have a problem with netscape 4.75 under RH6.2 with a  2.2.18pre1[67].

running it as root wirks fine, running it as ordinary user hangs very
fast.

The logs show several 

Oct 27 21:29:25 guinevere kernel: set_program_attributes(1200 d98000 1400
457440)

messages

I have tried this on 2 different Alpha-Types (Avanti, SX164) with several
tifferent compiling-options, bon without success.

Any suggestions how I can make netscape and maybe other Tru64 Binaries
work properly, since the alphas are in a cluster  with some Tru64 servers?

LL UK
-- 
===
Ulrich Kiermayr| Internet eMail:
Zentraler Informatikdienst der |  [EMAIL PROTECTED]
Universitaet Wien  |  [EMAIL PROTECTED]
   | --
   Abteilung Dezentrale Systeme| eMail Hotline-Service:
   Aussenstelle Physik |  [EMAIL PROTECTED]
   | --
Boltzmanngasse 5, A-1090 Vienna| Tel: +43-1-4277 /14104,Hotline: /14100
Austria, Europe| Fax: +43-1-4277 /9141
===

-
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] cpu detection fixes for test10-pre4

[H. Peter Anvin]

Horst von Brand wrote:
> 
> "H. Peter Anvin" <[EMAIL PROTECTED]>said:
> > Alan Cox wrote:
> 
> [...]
> 
> > > > We should never have used anything but "i386" as the utsname... sigh.
> 
> > > Its questionable if we should include the 'i'
> 
> > True enough, personally I prefer "x86".
> 
> ia32 is the official name. OTOH, i[3-6]86 _are_ different beasts...
> 

IA32 is a retcon, and is used only by Intel anyway.  There are
differences between the i686 lines that are significantly bigger than
between the i486 and i586, and that doesn't even begin to count non-Intel
chips.

However, changing it to "i386" consistently would still work with
existing software.  Using "x86" or "ia32" or "ix86pc" (what Solaris calls
it) would break stuff.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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: test[9-10] USB depmod unresolved symbols

[Dunlap, Randy]

Hunt, Claude, Jean-Luc:

I'm hoping that this will help explain some of
the confusion that you have been or are seeing,
although it doesn't explain it fully for me,
but maybe it does for someone else (like Keith
Owens ?).

I was able to reproduce the problem that Hunt
described below.  'depmod -ae' gave me similar
output (but lots more of them since I compiled
everything possible as a USB module -- except
for the USB core [USB Support option]).

I'm currently using 2.4.0-test10-pre6.
My normal (?) kernel has NO USB built into it.
That is, I normally build USB all as modules.
Call this no-USB kernel 't10pre6'.

But for this test, I built usbcore into the kernel.
Call this usbcore-kernel 't10pre6-kuc'.

Now if I am running 't10pre6' (no USB in kernel)
and I do 'depmod -ae', I get lots of these
"Unresolved symbol" messages from depmod.
However, if I boot 't10pre6-kuc' (USBcore in kernel)
and i do 'depmod -ae', it works fine, no errors.

Is this like what you are seeing?
Are you seeing depmod errors before loading
the kernel that includes the USB core?

And finally (for anyone), is this the normal,
expected usage & behavior of depmod?

Thanks,
~Randy


> From: Hunt Kent [mailto:[EMAIL PROTECTED]]
> 
> Okay, updates:
> 
>   Compiled modutils 2.3.19 and the problem persists.
> Arch is i386, AMD K-6.
> 
>   Result for modprobe -ae (test10-pre5):
> 
> depmod: *** Unresolved symbols in
> /lib/modules/2.4.0-test10-pre5/kernel/drivers/usb/dc2xx.o
> depmod: usb_bulk_msg
> depmod: usb_deregister
> depmod: usb_free_dev
> depmod: usb_inc_dev_use
> depmod: usb_register
> depmod: *** Unresolved symbols in
> /lib/modules/2.4.0-test10-pre5/kernel/drivers/usb/ov511.o
> depmod: usb_deregister
> depmod: usb_free_urb
> depmod: usb_alloc_urb
> depmod: usb_register
> depmod: usb_submit_urb
> depmod: usb_driver_release_interface
> depmod: usb_control_msg
> depmod: usb_set_interface
> depmod: usb_unlink_urb
> depmod: *** Unresolved symbols in
> /lib/modules/2.4.0-test10-pre5/kernel/drivers/usb/printer.o
> depmod: usb_deregister
> depmod: usb_register
> depmod: usb_submit_urb
> depmod: usb_set_interface
> depmod: usb_unlink_urb
> depmod: *** Unresolved symbols in
> /lib/modules/2.4.0-test10-pre5/kernel/drivers/usb/scanner.o
> depmod: usb_bulk_msg
> depmod: usb_deregister
> depmod: usb_register
> depmod: usb_submit_urb
> depmod: usb_driver_release_interface
> depmod: usb_unlink_urb
> 
>   Let me know if you need more info.

-
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: NCPFS flags all files executable on NetWare Volumes wit

[Jeff V. Merkey]

Petr,

Here's the complete set of 3.x/4.x/5.x Namespace NCP calls with proper
return codes.  I'll run down the huge-data info and post a bit later.

1.

NCP  code  /5716

Generate Directory Base and Volume Number

Returns the directory base for the file or directory in the name space
associated with
"namespace"

Request Packet (20 to ? bytes)

indexbytes   type or valuedescription
0 6structure  Request Packet Header
6 20x5716 NCP Function Code
8 1Namespace  Namespace number (0-DOS, 2-NFS,
4-LONG, 1-MAC)
9 3reserved   '000''s
121Volume Number  The volume the file resides in.
134   ComponentHandle
171   ComponentHandleFlag
181   The number of components in
ComponentPath
191...?   ComponentPath

Reply Packet (17 bytes)

indexbytes   type or valuedescription

0 8structure  Server Response Header
8 4   The directory base of the file or
directory in the 
  namespace associated with
Namespace
124   The directory base of the file or
directory in the DOS Name Space (The FAT Chain head)
161   Volume Number


Completion codes

0x00  OK

2.

NCP code /5717

Query Name Space Information Format

Attempts to return the format of the information for the specified name
space on the volume associated with VolumeNumber.

Request Packet (10 bytes)

index bytestype or value  description

0  6structure  Request Packet Header
6  20x5717 NCP Function Code
8  1   Namespace
9  1   Volume Number


Reply Packet (154 bytes)

index bytestype or value  description

0  8structure  ServerResponseHeader
8  4   fixed bit mask
12 4   variable bit mask
16 4   huge bit mask
20 2   fixed bits defined
22 2   variable bits defined
24 2   huge bits defined
26 128 fields length table  (for NFS,
this is the NFS structure in NWDIR.H in NWFS)

Completion codes

0x00   OK


3.

NCP code /5719

Set Name Space Information

Attempts to set iformation specific to the name space for the specified
entity.

Request Packet (531 bytes)

index bytestype or value description

0  6structureRequestPacketHeader
6  20x5719   NCPFunctionCode
8  1 Source Name Space
9  1 Destination Name Space
10 1 Volume Number
11 4 DirEntry
15 4 NSInfoBitMask
19 512   NSSpecificInfo  (the modified
namespace records)

Reply Packet (8 bytes)

index  bytestype or valuedescription

0  8structureServerResponseHeader

Completion Codes

0x00   OK


4.   

NCP code222/571B

Set Huge Name Space Information

Attempts to set the huge Namespace information for the entity associated
with DirEntry

Request Packet (39 bytes)

index  bytes type of value description

0   6 structure RequestPacketHeader
6   2 0x571BNCPFunctionCode
8   1   Namespace
9   1   Volume Number
10  4   DirEntry
14  4   HugeMask
18 16   HugeStateInfo
34  4   HugeDataLength
38  1   HugeData

Reply Packet (28 bytes)

index bytes  type or value description

0   8 structure ServerResponseHeader
8  16   HugeStateInfo
24  4   Total Amount of Huge Data Used

Completion Code

0x00  OK


I have the formats for the other NameSpace NCPs, but it looks like your
code is handling these.  If you need them,
let me know.  I have a 600 page document I wrote two years ago that
details every single NCP and NDS NCP used,
and can send it to you via UPS in .cz.   It's too big to fax, or post.


The format of the namespace records is the same as in NWDIR.H in NWFS --
NetWare just passes them through to the client
so all the field layouts are there.  Unless the NFS server is loaded on
NetWare, you can just about write anythin you
want 

Re: [PATCH] cpu detection fixes for test10-pre4

[Horst von Brand]

"H. Peter Anvin" <[EMAIL PROTECTED]>said:
> Alan Cox wrote:

[...]

> > > We should never have used anything but "i386" as the utsname... sigh.

> > Its questionable if we should include the 'i'

> True enough, personally I prefer "x86".

ia32 is the official name. OTOH, i[3-6]86 _are_ different beasts...
-- 
Dr. Horst H. von Brand   mailto:[EMAIL PROTECTED]
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
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: GPL Question

[James Sutherland]

On Fri, 27 Oct 2000, David Schwartz wrote:

> 
> > Now, if a module is loaded that registers a set of functions that have
> > increased functionality compared to the original functions, if that
> > modules is not based off GPL'd code, must the source code of that module
> > be released under the GPL?
> 
>   If the answer to this is "yes", then Microsoft should own some rights to
> every piece of software that uses the Windows API.

In fact, since you call the Windows API by linking against Windows
libraries (kernel32.dll etc), Microsoft have as much right to dictate the
licensing of Windows apps as the FSF has to require apps linked against
GPLed code to be GPLed. (IMO, neither has any such right; of course, given
the spate of recent laws we've seen, I wouldn't put any faith in a legal
system to reach the "right" decision...)

In this particular case - just communicating with GPLed code - the answer
is no, you are not required to impose GPL restrictions on your users, you
can use a free license instead (or a proprietary one, if you really
want...)


James.

-
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/

Question: multiple major numbers - one driver

[chris parker]

I have a need for more than 256 minor numbers.  I could add some 
more major numbers, thus getting the number of majors * 256.
I would like to have only device driver loaded to handle the
multiple majors.
I thoought of the following things that would have to be changed: 

1) make the new device descriptors
2) add the new majors to the register_blkdev and unregister
   system calls
3) process multiple CURRENT q's when receiving a request 
   from the block device layer. Each unique major has
   a seperate incoming q.

   Does any know of anything else that would prevent me from doing 
   this ??

-
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: missing mxcsr initialization

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Alan Cox <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> > 
> > and it appears to work again, until it turns out that Cyrix has the same
> > issue, and then it ends up being the test from hell, where different
> > vendor tests all clash, and it gets increasingly difficult to add a new
> > thing later on sanely. 
> 
> And you end up with mtrr.c
> 

Indeed.

> 
> > No thank you. We'll just require fixed feature flags. Which can be turned
> > on as the features are enabled.
> 
> That seems sensible
> 

I'm working on the patch right now.

-hpa
-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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: mkraid

[Jakob Østergaard]

On Fri, Oct 27, 2000 at 10:56:16AM -0700, Anil kumar wrote:
> Hi,
>   
>  I have a problem with mkraid 

This is Linux-RAID specific and not material for the linux-kernel
list.

Please, just post your questions to linux-raid, not linux-kernel.

And most importantly, when you ask me these exact same questions in direct
e-mail anyway, it is a little wasteful to also trouble this list with your
question as well.

Thank you,
 (and you got the answer in the reply to the direct mail two minutes ago)

-- 

:   [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: GPL Question

[Rik van Riel]

On Fri, 27 Oct 2000, David Schwartz wrote:

> > Now, if a module is loaded that registers a set of functions that have
> > increased functionality compared to the original functions, if that
> > modules is not based off GPL'd code, must the source code of that module
> > be released under the GPL?
> 
>  If the answer to this is "yes", then Microsoft should own
> some rights to every piece of software that uses the Windows
> API.

Read the fine print...

*runs like crazy*

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/   http://www.surriel.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/

IDE patches for 2.2.18-pre17

[I Lee Hetherington]

Does anyone have the IDE patches updated for 2.2.18-pre17?  The version
for 2.2.18-pre3 has a lot of rejects when applied to pre17, and I
figured I'd see if someone has worked them out already.

Thank in advance.

--Lee Hetherington




-
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: Supporting extended attributes and named streams on Posix OSes

[Michael Rothwell]

I saw that a number of people downloaded the document; did anyone read
it?

-M

Michael Rothwell wrote:
> 
> I realize all of this is 2.5 material.
> 
> We had been talking about this earlier, until Viro and Cox told us to
> quit until 2.5.
> 
> Alexander Viro wrote:
> >
> > It goes off-list.
> 
> But, in light of Andreas Gruenbacher's proposal
> (http://lwn.net/2000/1026/a/extended-attributes.php3) and Stephen
> Tweedie's proposal (http://lwn.net/2000/1026/a/sct-attributes.php3), I
> thought I should re-send our proposal
> (http://www.flyingbuttmonkeys.com/DraftStandard-MRR-4.pdf).
> 
> Please read and comment! :)
> 
> -M
> -
> 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/
-
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: GPL Question

[David Schwartz]

> Now, if a module is loaded that registers a set of functions that have
> increased functionality compared to the original functions, if that
> modules is not based off GPL'd code, must the source code of that module
> be released under the GPL?

If the answer to this is "yes", then Microsoft should own some rights to
every piece of software that uses the Windows API.

DS

-
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-global-2.2.18pre17-7

[octave klaba]

> The Becker's driver from ftp://ftp.scyld.com/pub/network/eepro100.c cures
> the error messages, 
yes. even is setup is not clean, it seems to work with 24-25Mbs since
I have no errors.

> but the network still stalls, and worse yet, seems to
> stall forever (as opposed to few minutes with 2.2.18pre17 driver).
after 2h it still works. maybe it will crash later. check it later.

octave
-
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] cpu detection fixes for test10-pre4

[H. Peter Anvin]

Alan Cox wrote:
> 
> > >   - make Pentium IV and other post-P6 processors use the "i686"
> > > family name (same fix as the system_utsname.machine init fix
> > > which went into include/asm-i386/bugs.h in test10-pre4)
> > >
> >
> > We should never have used anything but "i386" as the utsname... sigh.
> 
> Its questionable if we should include the 'i'
>

True enough, personally I prefer "x86".

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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: Big file support in Linux 2.2

[Matti Aarnio]

On Fri, Oct 27, 2000 at 12:02:44PM -0600, Andreas Dilger wrote:

> There may be other sources.  You also need to have a newer glibc (or recompile
> your own) to really support LFS.

However all software is *not* written to use LFS extended versions
of things.  Often using defines of:

-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64

in the Makefile of said software CFLAGS is enough, but that may
still sometimes not be enough.  Specifically if the system will
then use some libraries which are not LFS compatible.

> Cheers, Andreas
> http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert

/Matti Aarnio
-
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: Somewhat different GPL Question

[Rik van Riel]

On Fri, 27 Oct 2000, Christopher Friesen wrote:

> If I use some GPL'd code and make calls from my software to the
> GPL'd code, do I need to make *my* code available?  Or would I
> only have to make available any changes to the GPL'd code?
>
> Section 2.b of the GPL seems to indicate that I need to make the
> source for my entire executable available if it incorporates any
> GPL'd source, and that I cannot charge for the software, only
> for its distribution.  Is this correct?

It depends.

If you're making interprocess calls to call the GPL code,
I suspect you won't have to make your code GPL.

OTOH, if you /link/ against a GPL shared library, you will
have to GPL the source of your program (that is, you'll have
to give it to the people who receive the binary from you).

Mind that lots of the "system" libraries are under the
somewhat more free LPGL...

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/   http://www.surriel.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: Big file support in Linux 2.2

[Andreas Dilger]

Joe writes:
> For one of our projects here, we've crashed head first into the 2 gig file
> size limitation in Linux 2.2 kernels. While I know that this has been solved
> in 2.3/2.4, has there been any work to backport this feature into a Linux 2.2
> kernel? I'm looking for a temporary solution until we can move to Linux 2.4
> directly, but obviously not until after it's been "really" released. :)

You can get a 2.2 LFS patch from:
http://www.scyld.com/software/lfs.html

There may be other sources.  You also need to have a newer glibc (or recompile
your own) to really support LFS.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Somewhat different GPL Question

[Christopher Friesen]

If I use some GPL'd code and make calls from my software to the GPL'd
code, do I need to make *my* code available?  Or would I only have to
make available any changes to the GPL'd code?

Section 2.b of the GPL seems to indicate that I need to make the source
for my entire executable available if it incorporates any GPL'd source,
and that I cannot charge for the software, only for its distribution. 
Is this correct?

Thanks,
Chris

-- 
Chris Friesen| MailStop: 043/33/F10  
Nortel Networks  | work: (613) 765-0557
3500 Carling Avenue  | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada| email: [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: [PATCH] cpu detection fixes for test10-pre4

[Tim Riker]

Alan Cox wrote:
> 
> > >   - make Pentium IV and other post-P6 processors use the "i686"
> > > family name (same fix as the system_utsname.machine init fix
> > > which went into include/asm-i386/bugs.h in test10-pre4)
> > >
> >
> > We should never have used anything but "i386" as the utsname... sigh.
> 
> Its questionable if we should include the 'i'

heh, agreed. let's rename 'em all x86 and be done with it. ;-)

-- 
Tim Riker - http://rikers.org/ - short SIGs! 
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
-
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/

mkraid

[Anil kumar]

Hi,
  
 I have a problem with mkraid 

 I am working on a Red hat Linux ver 7.0
 kernel version: 2.2.16
 No raid patch
 no raid tools

 when I run
 #mkraid /dev/md0
  
  when I check /proc/mdstat,I find md0 active
  with raid information.
  
  But when again I run 
  #mkraid /dev/md0
  I get an message:
  handling MD device /dev/md0
  analyzing super-block
  disk 0:/dev/hde1,2109681kB,raid superblock at 
 2109568KB
  /dev/hde1 appears to be already part of a raid
array-- use -f to force desctruction of the old
superblock
mkraid: aborted,see the syslog and /proc/mdstat for
 potential clues.

 I tried -f option, but no use.

I did a reboot and once again mkraid, but still
 I get the above messages.
 Please let me know where am I wrong , How can I
 do mkraid succesfully again?

 Expecting reply from you

with regards,
  Anil

__
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.
http://im.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: VM-global-2.2.18pre17-7

[Jeff Nguyen]

Alan,

I agree with your point. In term of usability, the e100 driver has a wider
range of support for the Intel NIC cards.

Jeff

- Original Message -
From: Alan Cox <[EMAIL PROTECTED]>
To: Jeff Nguyen <[EMAIL PROTECTED]>
Cc: Ville Herva <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, October 27, 2000 10:16 AM
Subject: Re: VM-global-2.2.18pre17-7


> > You should use the Intel e100 driver at
> > http://support.intel.com/support/network/adapter/pro100/100Linux.htm.
> > It works much better than eepro100.
>
> Thats not the general consensus, but its worth trying in case it works
best
> for a given problem. In paticular it knows about bugs with combinations of
> transceivers which the eepro100 driver does not.
> -
> 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/

-
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: Full preemption issues

[Linus Torvalds]

On Fri, 27 Oct 2000, George Anzinger wrote:
> 
> First, as you know, we have added code to the spinlock macros to count
> up and down a preemption lock counter.  We would like to not do this if
> the macro also turns off local interrupts.  The issue here is that in
> some places in the code, spin_lock_irq() or spin_lock_irqsave() is
> called but spin_unlock_irq() or spin_lock_irqrestore() is not.  This, of
> course, confuses the preemption count.  Attached is a patch that
> addresses this issue.  At this time we are not asking you to apply this
> patch, but to indicate if we are moving in an acceptable direction.

Looks entirely sane to me.

> The second issue resolves around the naming conventions used in the
> kernel.  We want to extend this work to include the SMP kernel, but to
> do this we need to have several levels of names for the spinlock
> macros.  We note that the kernel uses "_" and "__" prefixes in some
> macros, but can not, by inspection, figure out when to uses these
> prefixes.  Could you explain this convention or is this wisdom written
> somewhere?

The "wisdom" is not written down anywhere, and is more a convention than
anything else. The convention is that a prepended "__" means that "this is
an internal routine, and you can use it, but you should damn well know
what you're doing if you do". For example, the most common use is for
routines that need external locking - the version that does its own
locking and is thus "safe" to use in normal circumstances has the regular
name, and the version of the routine that does no locking and depends on
the caller to lock for it has the "__" version.

Your proto code does not break this convention in any way..

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/

Full preemption issues

[George Anzinger]

Dear Linus,

As you know we at MontaVista are working on a fully preemptable kernel. 
In this work we have come up with a couple of issues we would like your
comments on.

First, as you know, we have added code to the spinlock macros to count
up and down a preemption lock counter.  We would like to not do this if
the macro also turns off local interrupts.  The issue here is that in
some places in the code, spin_lock_irq() or spin_lock_irqsave() is
called but spin_unlock_irq() or spin_lock_irqrestore() is not.  This, of
course, confuses the preemption count.  Attached is a patch that
addresses this issue.  At this time we are not asking you to apply this
patch, but to indicate if we are moving in an acceptable direction.

The second issue resolves around the naming conventions used in the
kernel.  We want to extend this work to include the SMP kernel, but to
do this we need to have several levels of names for the spinlock
macros.  We note that the kernel uses "_" and "__" prefixes in some
macros, but can not, by inspection, figure out when to uses these
prefixes.  Could you explain this convention or is this wisdom written
somewhere?

To clarify the intent here is a bit of proto code:

#ifdef CONFIG_PREEMPT
#define preempt_lock() ... definition...
#define preempt_unlock() ...definition...
#else
#define preempt_lock()
#define preempt_unlock()
#endif

#ifdef CONFIG_SMP
#define _spin_lock(x) __spin_lock(x)  /* __spin_lock(x) to be todays SMP
definition */
#define _spin_unlock(x) __spin_unlock(x)  /* __spin_unlock(x) to be
todays SMP definition */
#else
#define _spin_lock()
#define _spin_unlock()
#endif

#define spin_lock(x) do{ preempt_lock(); _spin_lock(x);} while (0)
#define spin_unlock(x) do{ _spin_unlock(x); preempt_unlock();} while (0)

George

diff -urP -X patch.exclude linux-2.4.0-test6-kb-p-r-i-6-1.4/drivers/ide/ide.c 
linux/drivers/ide/ide.c
--- linux-2.4.0-test6-kb-p-r-i-6-1.4/drivers/ide/ide.c  Thu Jul 27 16:40:57 2000
+++ linux/drivers/ide/ide.c Fri Oct 20 13:06:45 2000
@@ -1354,7 +1354,7 @@
 */
if (masked_irq && hwif->irq != masked_irq)
disable_irq_nosync(hwif->irq);
-   spin_unlock(_request_lock);
+   spin_unlock_noirqrestore(_request_lock);
ide__sti(); /* allow other IRQs while we start this request */
startstop = start_request(drive);
spin_lock_irq(_request_lock);
@@ -1438,7 +1438,7 @@
 * the handler() function, which means we need to globally
 * mask the specific IRQ:
 */
-   spin_unlock(_request_lock);
+   spin_unlock_noirqrestore(_request_lock);
hwif  = HWIF(drive);
 #if DISABLE_IRQ_NOSYNC
disable_irq_nosync(hwif->irq);
@@ -1599,7 +1599,7 @@
}
hwgroup->handler = NULL;
del_timer(>timer);
-   spin_unlock(_request_lock);
+   spin_unlock_noirqrestore(_request_lock);
 
if (drive->unmask)
ide__sti(); /* local CPU only */
--- linux-2.4.0-test6-org/include/linux/spinlock.h  Wed Aug  9 18:57:54 2000
+++ linux/include/linux/spinlock.h  Fri Oct 27 09:48:47 2000
@@ -7,29 +7,107 @@
  * These are the generic versions of the spinlocks and read-write
  * locks..
  */
-#define spin_lock_irqsave(lock, flags) do { local_irq_save(flags);   
spin_lock(lock); } while (0)
-#define spin_lock_irq(lock)do { local_irq_disable(); 
spin_lock(lock); } while (0)
-#define spin_lock_bh(lock) do { local_bh_disable();  
spin_lock(lock); } while (0)
-
-#define read_lock_irqsave(lock, flags) do { local_irq_save(flags);   
read_lock(lock); } while (0)
-#define read_lock_irq(lock)do { local_irq_disable(); 
read_lock(lock); } while (0)
-#define read_lock_bh(lock) do { local_bh_disable();  
read_lock(lock); } while (0)
-
-#define write_lock_irqsave(lock, flags)do { local_irq_save(flags);
  write_lock(lock); } while (0)
-#define write_lock_irq(lock)   do { local_irq_disable();
write_lock(lock); } while (0)
-#define write_lock_bh(lock)do { local_bh_disable(); 
write_lock(lock); } while (0)
-
-#define spin_unlock_irqrestore(lock, flags)do { spin_unlock(lock);  
local_irq_restore(flags); } while (0)
-#define spin_unlock_irq(lock)  do { spin_unlock(lock);  
local_irq_enable();   } while (0)
-#define spin_unlock_bh(lock)   do { spin_unlock(lock);  
local_bh_enable();} while (0)
-
-#define read_unlock_irqrestore(lock, flags)do { read_unlock(lock);  
local_irq_restore(flags); } while (0)
-#define read_unlock_irq(lock)  do { read_unlock(lock);  
local_irq_enable();   } while (0)
-#define 

Re: GPL Question

[Mark Salisbury]

On Fri, 27 Oct 2000, Jason Wohlgemuth wrote:
> Consider this:
> 
> A subsystem that is statically built into the Linux Kernel is modified 
> to allow the registration of a structure containing function pointers.
> 
> The function pointers corrolate to a set of functions within that subsystem.
> If the new structure of pointers has been registered, the original 
> functions will call the new functions in the structure passing all 
> arguments and returning the return value of the new function.
> 
> With this said, if no structure has been registered, then no 
> functionality is degraded within the kernel.  Only the loss of some cpu 
> time to check the pointers at the top of the old functions.
> 
> Now, if a module is loaded that registers a set of functions that have 
> increased functionality compared to the original functions, if that 
> modules is not based off GPL'd code, must the source code of that module 
> be released under the GPL?
> 
> Thanks in advance,
> Jason Wohlgemuth


the api of the module would be a reimplementation of a GPL'd api
(the function names may have changed, but the base behaviors must be equivalent)

so the question in simple terms might phrased as:

is the API under GPL, or is it the code or are both?

I think the answer is both.
-- 
/***
**   Mark Salisbury | Mercury Computer Systems**
**   [EMAIL PROTECTED] | **
****
**  "WYGIWYD - What You Get Is What You Deserve"  **
***/


-
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: GPL Question

[Matthew Dharm]

On Fri, Oct 27, 2000 at 06:21:27PM +0100, Alan Cox wrote:
> > On Fri, 27 Oct 2000, Jason Wohlgemuth wrote:
> > 
> > > Now, if a module is loaded that registers a set of functions that have 
> > > increased functionality compared to the original functions, if that 
> > > modules is not based off GPL'd code, must the source code of that module 
> > > be released under the GPL?
> > 
> > It would probably follow GPL, but it's pretty slimy. I won't buy it.
> 
> It depends primarily if the module depends on the code which is GPL. Its all
> a rather unclear area. 

Legally, I think this is probably unclear.  But, I have my own, personal
standard I use for this.

The question in my mind is one of "can it stand alone".  In the example
originally mentioned, the new module (let's call it the alpha module)
registers function calls with the old module (let's call it beta).

Now, the question in my mind is this:  Is alpha a replacement for beta? It
certainly sounds like it.  But it depends of what/how many functions are
being overridden.  Are there other functions from beta which are used by
alpha (either as above alpha or below it)?  What are these replacement
functions trying to do?  If you're using an allready existing abstraction
layer, then you're probably okay... but if you're really inventing a new
abstraction layer, then you're probably not okay.

I guess what I'm saying is this: It all comes down to intent for me.  Yeah,
that's a lousy standard to use, especially in a courtroom.  But that's what
I really care about in the end.

Matt

-- 
Matthew Dharm  Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

We can customize our colonels.
-- Tux
User Friendly, 12/1/1998

 PGP signature

Re: GPL Question

[Alan Cox]

> Now, if a module is loaded that registers a set of functions that have 
> increased functionality compared to the original functions, if that 
> modules is not based off GPL'd code, must the source code of that module 
> be released under the GPL?

Consult a Copyright/'Intellectual Property' lawyer.  I wouldnt ask a lawyer
to write a kernel driver, I would suggest not asking kernel hackers to do law 8)

-
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: GPL Question

[Alan Cox]

> On Fri, 27 Oct 2000, Jason Wohlgemuth wrote:
> 
> > Now, if a module is loaded that registers a set of functions that have 
> > increased functionality compared to the original functions, if that 
> > modules is not based off GPL'd code, must the source code of that module 
> > be released under the GPL?
> 
> It would probably follow GPL, but it's pretty slimy. I won't buy it.

It depends primarily if the module depends on the code which is GPL. Its all
a rather unclear area. 

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: VM-global-2.2.18pre17-7

[Alan Cox]

> You should use the Intel e100 driver at
> http://support.intel.com/support/network/adapter/pro100/100Linux.htm.
> It works much better than eepro100.

Thats not the general consensus, but its worth trying in case it works best
for a given problem. In paticular it knows about bugs with combinations of
transceivers which the eepro100 driver does not.
-
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: NCPFS flags all files executable on NetWare Volumes wit

[Jeff V. Merkey]

On Fri, Oct 27, 2000 at 10:57:54AM -0600, Jeff V. Merkey wrote:
> On Fri, Oct 27, 2000 at 03:00:31PM +, Petr Vandrovec wrote:
> > On 27 Oct 00 at 0:16, Jeff V. Merkey wrote:
> > > I noticed NCPFS is flagging all the files on a native NetWare volume as
> > > executable and chmod -x does not work, even if the NetWare server has 
> > > the NFS namespace loaded.  I looked at you code in more detail, and I 
> > > did not see support their for the NFS/Unix namespace.  
> > 
> > > Is this in a newer version, or has it not been implemented yet?  I was
> > > testing with MARS and Native NetWare this evening and saw this.  If the 
> > > NFS namespace is loaded, you should be able to get to it and access and 
> > > set all these bits in the file system namespace directory records.
> > > 
> > > Do you need any info from me to get this working, or is there another
> > > version where I can get this for Ute-Linux?
> > 
> > Hi Jeff,
> >   ncpfs does not support NFS fields, as access through namespace functions
> > is hopelessly broken (modify ns specific info has swapped some bits
> > in mask which data update and which not), and it also adds some (100%)
> > overhead on directory/inode lookups, as you must ask twice - first for
> > non-NFS info, and second for NFS specific...
> > 
> >   There exists patch from Ben Harris <[EMAIL PROTECTED]>, which adds
> > this feature to 2.2.16 kernel and 2.2.0.17 ncpfs. You can download
> > it from ftp://platan.vc.cvut.cz/pub/linux/ncpfs/ncp{1,2}.pat. ncp1.pat
> > is kernel patch (including email headers; cut them if applying), ncp2.pat
> > is patch for 2.2.0.17 ncpfs userspace - it adds mount option "nfsextras".
> > (I apologize to Ben - I promised to integrate it into ncpfs, and into
> > 2.4 kernel, but...)
> > 
> >   Except that, you can make all files non-executable by using
> > "filemode=0644" mount option. Or you can use "extras,symlinks", in which
> > case (NFS namespace incompatible) hidden/shareable/transactional attributes
> > are used to signal executability of file...
> > 
> >   If you have some document which describes what each NFS specific field 
> > does - currently ncpfs names them "name", "mode", "gid", "nlinks", "rdev",
> > "link", "created", "uid", "acsflag" and "myflag" - if I remember correctly,

Oh, and:

created is always set to 1 for the root entry.
acsflag is whehter NetWare or the NFS client last accessed the file
name is the name
mode CANNOT contain NFS v3.0 style permissions it's on v2.0 -- pipe and 
fifo will hang the NetWare server, so mask these off.
nlinks is the number of hardlinks to a file.
rdev is the same as rdev in Linux
flags(myflag) contains the following values:

#define NFS_HASSTREAM_HARD_LINK  1  // indicates this record has the FAT chain
#define NFS_SYMBOLIC_LINK2
#define NFS_HARD_LINK3

There's also three linkage fields you have to fill out:

LinkNextDirNo   // next record in the hardlink chain
LinkEndDirNo// always the dir record that holds the fat chain
LinkPreDirNo// previous record in the hardlink chain

records are added at the HEAD and not the TAIL of the linkage.  The 
root record is always at the END and not the HEAD of the list.

:-)

Jeff

I'll go dig up the specific NCP extensions and get them to you.

:-)

Jeff

> > it is how Unixware 2.0 nuc.h names them. And I did not found any information
> > about layout of NFS huge info, which is used for hardlinks :-(
> > 
> >   Also, as NCP 87,8 kills almost every NW server I know, if used namespace
> > is NFS, I'm a bit sceptic about usability of NCP 87,* on NFS namespace.
> > 
> >   In 1998 and 1999 I tried to ask Novell for documentation of NCP 95,*
> > (Netware Unix Client), but it was refused and ignored, so... here we are.
> > Best regards,
> > Petr Vandrovec
> > [EMAIL PROTECTED]
> 
> 
> Petr,
> 
> I've got the info you need including the layout of the NFS namspace 
> records.  For a start, grab NWFS and look at the NFS structure in 
> NWDIR.H.  The fields you have to provide are there.  There are some 
> funky ones in this structure.  You are correct regarding the NCP 
> extensions to support this.  They are about 12 years old, BTW and are 
> not even supported any longer (no one has worked on this at Novell 
> since about 1994).  
> 
> I will put together a complete description today (will take a couple 
> of hours) and post to the list on the implementation of of the NFS
> namespace over the wire.  Hardlinks use a root DirNo handle that 
> must point back to the DOS namespace record that owns the FAT chain
> and this is probably the only nasty thing to deal with here.
> 
> I'll get started immediately.
> 
> :-)
> 
> Jeff
> 
> 
> 
> 
> > 
> > P.S.: Jeff, if you want, there is ncpfs/MaRS/LinWare specific list,
> > [EMAIL PROTECTED] 

Re: NCPFS flags all files executable on NetWare Volumes wit

[Jeff V. Merkey]

On Fri, Oct 27, 2000 at 03:00:31PM +, Petr Vandrovec wrote:
> On 27 Oct 00 at 0:16, Jeff V. Merkey wrote:
> > I noticed NCPFS is flagging all the files on a native NetWare volume as
> > executable and chmod -x does not work, even if the NetWare server has 
> > the NFS namespace loaded.  I looked at you code in more detail, and I 
> > did not see support their for the NFS/Unix namespace.  
> 
> > Is this in a newer version, or has it not been implemented yet?  I was
> > testing with MARS and Native NetWare this evening and saw this.  If the 
> > NFS namespace is loaded, you should be able to get to it and access and 
> > set all these bits in the file system namespace directory records.
> > 
> > Do you need any info from me to get this working, or is there another
> > version where I can get this for Ute-Linux?
> 
> Hi Jeff,
>   ncpfs does not support NFS fields, as access through namespace functions
> is hopelessly broken (modify ns specific info has swapped some bits
> in mask which data update and which not), and it also adds some (100%)
> overhead on directory/inode lookups, as you must ask twice - first for
> non-NFS info, and second for NFS specific...
> 
>   There exists patch from Ben Harris <[EMAIL PROTECTED]>, which adds
> this feature to 2.2.16 kernel and 2.2.0.17 ncpfs. You can download
> it from ftp://platan.vc.cvut.cz/pub/linux/ncpfs/ncp{1,2}.pat. ncp1.pat
> is kernel patch (including email headers; cut them if applying), ncp2.pat
> is patch for 2.2.0.17 ncpfs userspace - it adds mount option "nfsextras".
> (I apologize to Ben - I promised to integrate it into ncpfs, and into
> 2.4 kernel, but...)
> 
>   Except that, you can make all files non-executable by using
> "filemode=0644" mount option. Or you can use "extras,symlinks", in which
> case (NFS namespace incompatible) hidden/shareable/transactional attributes
> are used to signal executability of file...
> 
>   If you have some document which describes what each NFS specific field 
> does - currently ncpfs names them "name", "mode", "gid", "nlinks", "rdev",
> "link", "created", "uid", "acsflag" and "myflag" - if I remember correctly,
> it is how Unixware 2.0 nuc.h names them. And I did not found any information
> about layout of NFS huge info, which is used for hardlinks :-(
> 
>   Also, as NCP 87,8 kills almost every NW server I know, if used namespace
> is NFS, I'm a bit sceptic about usability of NCP 87,* on NFS namespace.
> 
>   In 1998 and 1999 I tried to ask Novell for documentation of NCP 95,*
> (Netware Unix Client), but it was refused and ignored, so... here we are.
> Best regards,
> Petr Vandrovec
> [EMAIL PROTECTED]


Petr,

I've got the info you need including the layout of the NFS namspace 
records.  For a start, grab NWFS and look at the NFS structure in 
NWDIR.H.  The fields you have to provide are there.  There are some 
funky ones in this structure.  You are correct regarding the NCP 
extensions to support this.  They are about 12 years old, BTW and are 
not even supported any longer (no one has worked on this at Novell 
since about 1994).  

I will put together a complete description today (will take a couple 
of hours) and post to the list on the implementation of of the NFS
namespace over the wire.  Hardlinks use a root DirNo handle that 
must point back to the DOS namespace record that owns the FAT chain
and this is probably the only nasty thing to deal with here.

I'll get started immediately.

:-)

Jeff




> 
> P.S.: Jeff, if you want, there is ncpfs/MaRS/LinWare specific list,
> [EMAIL PROTECTED] Subscribe: "subscribe linware" to "[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: pcmcia in test10pre6

[Jeff V. Merkey]

On Fri, Oct 27, 2000 at 11:32:18AM +, Jonathan Hudson wrote:
> 
> Previously working in test10pre*, now gives many unresolved symbols:
> 
> 
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol cb_free
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol cb_disable
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_read_memory
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol cb_config
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_close_memory
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_register_mtd
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol read_tuple
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_check_erase_queue
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol cb_release_cis_mem
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol find_io_region
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol write_cis_mem
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_write_memory
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol undo_irq
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_request_irq
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_parse_tuple
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol cb_release
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol release_resource_db
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol cb_alloc
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol 
>pcmcia_get_first_region/lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol 
>release_cis_mem
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol try_irq
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_adjust_resource_info
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_get_next_region
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol cb_enable
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_copy_memory
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_get_tuple_data
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol verify_cis_cache
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol 
>pcmcia_deregister_erase_queue
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_register_erase_queue
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_get_first_tuple
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol MTDHelperEntry
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol read_cis_mem
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_get_next_tuple
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_replace_cis
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_open_memory
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_validate_cis
> /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol find_mem_region

Grab the pcmcia off sourceforge.  It seems to build and work.  The stuff 
in 2.4 at present is still somewhat broken.  I worked on this until 2:00
last night getting it to build with 2.4.  Thanks to Alan for pointing
me to a package that actually works and will build on 2.4.  

:-)

Jeff

> -
> 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/
-
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: GPL Question

[David Weis]

On Fri, 27 Oct 2000, Jason Wohlgemuth wrote:

> Now, if a module is loaded that registers a set of functions that have 
> increased functionality compared to the original functions, if that 
> modules is not based off GPL'd code, must the source code of that module 
> be released under the GPL?

It would probably follow GPL, but it's pretty slimy. I won't buy it.

david

-- 
David Weis| "Great spirits will always encounter violent
[EMAIL PROTECTED]   | opposition from mediocre minds" - Einstein
http://www.sjdjweis.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: kqueue microbenchmark results

[Alfred Perlstein]

* Dan Kegel <[EMAIL PROTECTED]> [001027 09:40] wrote:
> Alan Cox wrote:
> > > > kqueue currently does this; a close() on an fd will remove any pending
> > > > events from the queues that they are on which correspond to that fd.
> > > 
> > > the application of a close event.  What can I say, "the fd formerly known
> > > as X" is now gone?  It would be incorrect to say that "fd X was closed",
> > > since X no longer refers to anything, and the application may have reused
> > > that fd for another file.
> > 
> > Which is precisely why you need to know where in the chain of events this
> > happened. Otherwise if I see
> > 
> > 'read on fd 5'
> > 'read on fd 5'
> > 
> > How do I know which read is for which fd in the multithreaded case
> 
> That can't happen, can it?  Let's say the following happens:
>close(5)
>accept() = 5
>call kevent() and rebind fd 5
> The 'close(5)' would remove the old fd 5 events.  Therefore,
> any fd 5 events you see returned from kevent are for the new fd 5.
> 
> (I suspect it helps that kevent() is both the only way to
> bind events and the only way to pick them up; makes it harder
> for one thread to sneak a new fd into the event list without
> the thread calling kevent() noticing.)

Yes, that's how it does and should work.  Noticing the close()
should be done via thread communication/IPC not stuck into
kqueue.

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
-
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/

GPL Question

[Jason Wohlgemuth]

Consider this:

A subsystem that is statically built into the Linux Kernel is modified 
to allow the registration of a structure containing function pointers.

The function pointers corrolate to a set of functions within that subsystem.
If the new structure of pointers has been registered, the original 
functions will call the new functions in the structure passing all 
arguments and returning the return value of the new function.

With this said, if no structure has been registered, then no 
functionality is degraded within the kernel.  Only the loss of some cpu 
time to check the pointers at the top of the old functions.

Now, if a module is loaded that registers a set of functions that have 
increased functionality compared to the original functions, if that 
modules is not based off GPL'd code, must the source code of that module 
be released under the GPL?

Thanks in advance,
Jason Wohlgemuth

-
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: kqueue microbenchmark results

[Dan Kegel]

Alan Cox wrote:
> > > kqueue currently does this; a close() on an fd will remove any pending
> > > events from the queues that they are on which correspond to that fd.
> > 
> > the application of a close event.  What can I say, "the fd formerly known
> > as X" is now gone?  It would be incorrect to say that "fd X was closed",
> > since X no longer refers to anything, and the application may have reused
> > that fd for another file.
> 
> Which is precisely why you need to know where in the chain of events this
> happened. Otherwise if I see
> 
> 'read on fd 5'
> 'read on fd 5'
> 
> How do I know which read is for which fd in the multithreaded case

That can't happen, can it?  Let's say the following happens:
   close(5)
   accept() = 5
   call kevent() and rebind fd 5
The 'close(5)' would remove the old fd 5 events.  Therefore,
any fd 5 events you see returned from kevent are for the new fd 5.

(I suspect it helps that kevent() is both the only way to
bind events and the only way to pick them up; makes it harder
for one thread to sneak a new fd into the event list without
the thread calling kevent() noticing.)

- Dan
-
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: Off-Topic (or maybe on-topic)

[Art Boulatov]

David Weinehall wrote:
> 
> On Fri, Oct 27, 2000 at 04:05:50PM +0300, Petko Manolov wrote:
> > David Weinehall wrote:
> > >
> > > You're VERY wrong here. St. Petersburg was the name before the Soviet
> > > Union was formed and Russia marched into the Baltics. When the takeover
> > > was made, the city was renamed Leningrad (after V.I. Lenin). When the
> > > Soviet Union finally fell to pieces and the Baltics retained their freedom,
> > > St. Petersburg retained its old name, which it got (if I'm not all wrong)
> > > from Peter the Great.
> >
> >
> > AFAIK Tigran is born in the Soviet Union and i thing he knows
> > the history of his own country better ;-)
> 
> Uhmmm. You known, being born in the Soviet Union (not a country in its
> strictest sense), doesn't necessarily mean you know its history. And
> considering that the span of the SSSR was quite enormous...
> 
> Anyhow:
> 
> The city was originally called Nyen and was formed by Swedes. 1703,
> Peter the Great invaded the city, and 1712 the city became the capital
> of Russia, named St. Petersburg. The name remained St. Petersburg until
> 1914, when it was renamed Petrograd. 1918, Moscow was made the capital
> of Russia, and 1924 the city got renamed again, this time to Leningrad.
> 
> > Anyway, i am bulgarian and i also am used to call St. Petersburg
> > Leningrad ;-))
> 
> Well, it's time for me, as a Swede, to begin calling it Nyen?!
> 
> Oh, let's end this silly debate. I'm getting sorry I even brought it
> up.

Hi,

but since you did, :)

I will insist it is St. Petersburg :)

Art.
-
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: Blocked processes <=> Elevator starvation?

[Rik van Riel]

On Fri, 27 Oct 2000, Rui Sousa wrote:

> I finally had time to give this a better look. It now seems the
> problem is in the VM system.

*sigh*

> schedule()
> ___wait_on_page()
> do_generic_file_read()
> generic_file_read()
> sys_read()
> system_call()
> 
> So it seems the process is either in a loop in ___wait_on_page()
> racing for the PageLock or it never wakes-up... (I guess I could
> add a printk to check which)

It is spinning in ___wait_on_page() because the page never
becomes available, because the IO doesn't get scheduled to
disk in time.

This appears to be an elevator problem, not a VM problem.

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/   http://www.surriel.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: Blocked processes <=> Elevator starvation?

[Rui Sousa]

On Sun, 8 Oct 2000, Rik van Riel wrote:

> On Sun, 8 Oct 2000, Rui Sousa wrote:
> 
> > After starting 2 processes that scan a lot of files (diff, find,
> > slocate, ...) it's impossible to run any other processes that
> > touch the disk, they will stall until one of the first two stop.
> > Could this be a sign of starvation in the elevator code?
> 
> It could well be. I've seen this problem too and don't
> really have another explanation for this phenomenon.
> 
> OTOH, maybe there is another reason for it that hasn't
> been found yet ;)
> 

I finally had time to give this a better look. It now seems the problem
is in the VM system.

I patched a test10-pre4 kernel with kdb, then started two "diff -ur
linux-2.4.0testX linux-2.4.0testY > log1" and two "find / -true >
log". After this I tried cat"ing" a small file. The cat never 
returned. At this point I entered kdb and did a stack trace on the "cat"
process:

schedule()
___wait_on_page()
do_generic_file_read()
generic_file_read()
sys_read()
system_call()

So it seems the process is either in a loop in ___wait_on_page()
racing for the PageLock or it never wakes-up... (I guess I could add a
printk to check which)
Unfortunately I didn't find anything obviously wrong with the code.
I hope you can do a better job tracking the problem down.

As a reminder:
i686, UP, 64Mb RAM, IDE disks, ext2.

Rui Sousa

-
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.4.0-test9 + LFS

[kernel]

On Fri, 27 Oct 2000, David Weinehall wrote:

> On Fri, Oct 27, 2000 at 12:19:54PM -0400, Wakko Warner wrote:

> > That I do not know.  it's v 2.1.99  that came with debian in the past
> > week or so
> 
> Then it's compiled against the v2.2 kernel headers.

That explains why LFS isn't working then.  I strongly suggest that the
Debian glibc maintainers compile against 2.4 kernel headers or patch their
2.2 kernel headers to include the LFS stubs.

-ben

-
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: Off-Topic (or maybe on-topic)

[J. Dow]

From: <[EMAIL PROTECTED]>

> If Bill said 'screw you' to the blackmailer and made the press release,
> we should see the source on web sites soon.  Then we can see how bad it
> really is.  Maybe even fix it.

Dave, my partner has legal access to the MS source code. In some of my own
work I discovered an interesting apparent HAL bug related to the ACPI and
the PerformanceCounter API. A fix for a bad INTEL chip (24 bit counter that
doesn't always count correctly) was falsed by my K7M motherboard with a
700MHz Athlon on it. He adapts the HALs for some behemoth machines. So he
has seen the code involved. It is literally chock full of hacks and patches
and such - because of chip hardware defects. I'd be VERY careful about
casually going in and patching or repairing that source code based on such
dinnertable conversation about the HAL code as we've had. (I know no details.
I just know he regularly moans about it. - I bet he's having an interesting
day up there today. He's there for a meeting with the W2K folks. I'll have
to ask him how the anthill was today when he gets home.)

{^_-}Joanne Dow, [EMAIL PROTECTED], [EMAIL PROTECTED], [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: 2.4.0-test9 + LFS

[David Weinehall]

On Fri, Oct 27, 2000 at 12:19:54PM -0400, Wakko Warner wrote:
> > > I did upgrade that and it didn't help anything.
> > 
> > Was your glibc compiled against 2.4 kernel headers?
> 
> That I do not know.  it's v 2.1.99  that came with debian in the past
> week or so

Then it's compiled against the v2.2 kernel headers.


/David
  _ _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://www.tux.org/lkml/