EXPORT_SYMBOL for chrdev_open 2.4.3
It would be nice if chrdev_open were added to ksyms.c along with blkdev_open since tape devices seem are always registered as character rather than block devices. I am finding that kernel modules that need to open and close a tape drive have to export chrdev_open manually on 2.4.3. Can this get exported as well? Closing is not a problem since the method of calling (->release) seems to work OK with SCSI tape devices. :-) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EXPORT_SYMBOL for chrdev_open 2.4.3
On Fri, Apr 13, 2001 at 08:13:41PM -0400, Alexander Viro wrote: > > > On Fri, 13 Apr 2001, Jeff V. Merkey wrote: > > > It would be nice if chrdev_open were added to ksyms.c along with > > blkdev_open since tape devices seem are always registered as character > > rather than block devices. > > > > I am finding that kernel modules that need to open and close a tape > > drive have to export chrdev_open manually on 2.4.3. Can this get > > exported as well? Closing is not a problem since the method of > > calling (->release) seems to work OK with SCSI tape devices. > > They don't need it. Moreover, blkdev_open shouldn't be exported too - > the only potentially modular piece of code that refers to it is > drivers/block/rd.c and it's in initrd loading, so it isn't even > compiled when we do rd as a module. > > BTW, Linus, could we remove blkdev_open() from the export list? > I don't see any legitimate reason to export it - certainly not in > the official tree. > > BTW, fs/partitions/ibm.c also doesn't need blkdev_open() - it should > use ioctl_by_bdev() and be done with that. Al, How are folks supposed to open disk and tape devices from kernel modules without these? Not everything should be done in user space Al. If you remove blkdev_open I will not be able to properly increment the use count an a disk device I may be reading or writing to. Jeff > Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EXPORT_SYMBOL for chrdev_open 2.4.3
On Fri, Apr 13, 2001 at 06:38:10PM -0600, Jeff V. Merkey wrote: > On Fri, Apr 13, 2001 at 08:13:41PM -0400, Alexander Viro wrote: > > > > > > On Fri, 13 Apr 2001, Jeff V. Merkey wrote: > > > > > It would be nice if chrdev_open were added to ksyms.c along with > > > blkdev_open since tape devices seem are always registered as character > > > rather than block devices. > > > > > > I am finding that kernel modules that need to open and close a tape > > > drive have to export chrdev_open manually on 2.4.3. Can this get > > > exported as well? Closing is not a problem since the method of > > > calling (->release) seems to work OK with SCSI tape devices. > > > > They don't need it. Al, Not meaning to offend, but how could you know what everyone who uses Linux needs in every instance? NT, NetWare, etc. all expose these types of APIs for Backup and anti-virus software, etc. The APIs in question are the very calls user space apps call through the syscall to indicate who is using a device. Sure, I can send blind I/O requests to a device and I guess someone running fdisk in user space can blow the device away from beneath me since I have no way of locking those partitions I exclusively own and stopping this is these apis are removed and modules cannot call them. Jeff > > Moreover, blkdev_open shouldn't be exported too - > > the only potentially modular piece of code that refers to it is > > drivers/block/rd.c and it's in initrd loading, so it isn't even > > compiled when we do rd as a module. > > > > BTW, Linus, could we remove blkdev_open() from the export list? > > I don't see any legitimate reason to export it - certainly not in > > the official tree. > > > > BTW, fs/partitions/ibm.c also doesn't need blkdev_open() - it should > > use ioctl_by_bdev() and be done with that. > > > Al, > > How are folks supposed to open disk and tape devices from kernel modules > without these? Not everything should be done in user space Al. If you > remove blkdev_open I will not be able to properly increment the use > count an a disk device I may be reading or writing to. > > Jeff > > > > Al > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EXPORT_SYMBOL for chrdev_open 2.4.3
On Fri, Apr 13, 2001 at 09:25:10PM -0400, Alexander Viro wrote: > > > On Fri, 13 Apr 2001, Jeff V. Merkey wrote: > > > Not meaning to offend, but how could you know what everyone > > who uses Linux needs in every instance? NT, NetWare, etc. all > > expose these types of APIs for Backup and anti-virus software, > > etc. The APIs in question are the very calls user space apps > > call through the syscall to indicate who is using a device. > > Backup and AV software is not in the kernel, so they would > be unable to use the thing, exported or not. Please, don't > bring the strawmen. Some NT anti-virus stuff is in-kernel, and it's there to catch people writing viruses that act like device drivers. One day, if and when a Linux virus shows it's ugly head disguised as a kernel module, you will be backpeddling on this statement, and wishing we had in kernel anti-virus support. In W2K, folks have written some clever viruses that plug into their kernel as bogus device drivers. > > Novell's model (aka. "we don't need no stinkin' userland, everything > is NLM and security be damned") is better left to rot in hell with Novell. Well, I am working with them again, and they have taken quite a beating at our hands (and I sure didn't do them any good putting out the file system on Linux and free Migration tools). Saying the word "Linux" around Novell definitely solicits a very worried and serious response. I am trying to be nice to them -- Linux is eroding their installed base at light speed at this point. I'm sorry to say they show absolutely **NO** interest in doing things to promote Linux to their installed base in anyway that could benefit either them or Linux. > > > Sure, I can send blind I/O requests to a device and I guess > > someone running fdisk in user space can blow the device away from beneath > > me since I have no way of locking those partitions I exclusively > > own and stopping this is these apis are removed and modules > > cannot call them. > > Use filp_open() - it's that simple. Thanks. This is what I needed to know. I saw filp_open() in the EXPORTS file, but was uncertain if this would be an unchanging API. You have clarified this. I will convert my code to use this call instead. Linus, if Al wants the APIs removed from the export list, it sounds like filp_open() will handle future issues relative to my requirements, so I have no objection to them being removed. I'll let Al know if there are any problems with using them. Al, Thanks for the info. :-) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EXPORT_SYMBOL for chrdev_open 2.4.3
On Fri, Apr 13, 2001 at 09:29:43PM -0400, Alexander Viro wrote: > > On Fri, 13 Apr 2001, Jeff V. Merkey wrote: > > > How are folks supposed to open disk and tape devices from kernel modules > > without these? Not everything should be done in user space Al. If you > > Normally - filp_open(). If all you want is ioctl on block device - > blkdev_get() + ioctl_by_bdev() + blkdev_put(). If you want it by > device _number_ - use bdget(). > > > remove blkdev_open I will not be able to properly increment the use > > count an a disk device I may be reading or writing to. > > Yes, you will. And I would _really_ advice you to do that by > name instead of device number - that way you will avoid a lot of pain > couple of years down the road. This is **VERY** good to know, and also shows that you in fact have looked through my code. :-) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BUG() at line 804, slab.c, 2.4.3
I noticed that subsequent calls to kmem_cache_create with the same name does not return an -EEXIST return code, but instead barfs and crashes with a bug at slab.c line 804. This occurs in 2.4.3. Is this the expected behavior for kmem_cache_create? I am using the slab allocator to create and maintain buffer head chains for asynch I/O. I would assume that if a valid tag existed, an error would be returned rather than the system crashing. I see the problem unloading then reloading the module on 2.4.3. Thanks, Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG() at line 804, slab.c, 2.4.3
On Tue, Apr 17, 2001 at 03:29:20PM -0600, Jeff V. Merkey wrote: Added kmem_cache_destroy() to get around the problem. I'm still curious as to why we need to panic at this point rather than return an error. Thanks Jeff > > > I noticed that subsequent calls to kmem_cache_create with the same name > does not return an -EEXIST return code, but instead barfs and crashes > with a bug at slab.c line 804. This occurs in 2.4.3. > > Is this the expected behavior for kmem_cache_create? I am using > the slab allocator to create and maintain buffer head chains for > asynch I/O. > > I would assume that if a valid tag existed, an error would be returned > rather than the system crashing. I see the problem unloading then > reloading the module on 2.4.3. > > Thanks, > > Jeff > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
filp_open() in 2.2.19 causes memory corruption
I am now using the filp_open() call in kernel to scan for tape
devices in lieu of chrdev_open()/blkdev_open(), but I have
discovered that calling this api with non-existent devices
appears to result in memory corruption and some nasty oops.
I have attached the code fragment and oops generated by calling
ScanTapeDevices(). This basically works the way Al Viro described,
and I like the auto-probing of the tape device via calls to
filp_open(), which is really slick, if I can just get over
the oops, I think it's there.
Jeff
read enter
Unable to handle kernel paging request at virtual address c4035020
current->tss.cr3 = 03dcc000, %cr3 = 03dcc000
*pde = 03f7a063
*pte =
Oops:
CPU:0
EIP:0010:[sys_mremap+31/884]
EFLAGS: 00010206
eax: ebx: c3fefb00 ecx: c023e964 edx: c404d020
esi: c4035020 edi: c404d020 ebp: c3fefb60 esp: c238dd28
ds: 0018 es: 0018 ss: 0018
Process insmod (pid: 658, process nr: 23, stackpage=c238d000)
Stack: c238dd74 c238ddc8 0020 0020 ffe0 c3fefb6c c238dd50
0020 0004 0020 c4049c30 c404d020 0048 0020 2000
c4049d35 c025b5a0 c01cb0b1 000d
Call Trace:
[lockd:nlm4_granted_Rea24c726+123124/114388216]
[lockd:nlm4_granted_Rea24c726+136420/114374920]
[lockd:nlm4_granted_Rea24c726+123385/114387955]
[fbcon_cfb24_putc+69/808]
[lockd:nlm4_granted_Rea24c726+143844/114367496]
[lockd:nlm4_granted_Rea24c726+130960/114380380]
[lockd:nlm4_granted_Rea24c726+143588/114367752]
[lockd:nlm4_granted_Rea24c726+127420/114383920]
[lockd:nlm4_granted_Rea24c726+126445/114384895]
[lockd:nlm4_granted_Rea24c726+126268/114385072]
[lockd:nlm4_granted_Rea24c726+121676/114389664]
[lockd:nlm4_granted_Rea24c726+120083/114391257]
[lockd:nlm4_granted_Rea24c726+144284/114367056]
[ide_timer_expiry+172/436]
[lockd:nlm4_granted_Rea24c726+126932/114384408]
[lockd:nlm4_granted_Rea24c726+120004/114391336]
[lockd:nlm4_granted_Rea24c726+127808/114383532]
[lockd:nlm4_granted_Rea24c726+120004/114391336]
[getrusage+263/924]
[lockd:nlm4_granted_Rea24c726+142028/114369312]
[lockd:nlm4_granted_Rea24c726+87236/114424104]
[lockd:nlm4_granted_Rea24c726+120076/114391264]
[do_signal+512/616]
Code: ac ae 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 75 d9
BYTE *scsi_tape_handles[] =
{
"/dev/st0", "/dev/st1", "/dev/st2", "/dev/st3", "/dev/st4",
"/dev/st5", "/dev/st6", "/dev/st7", "/dev/st8", "/dev/st9",
"/dev/st10", "/dev/st11", "/dev/st12", "/dev/st13", "/dev/st14",
"/dev/st15", "/dev/st16", "/dev/st17", "/dev/st18", "/dev/st19",
"/dev/st20", "/dev/st21", "/dev/st22", "/dev/st23", "/dev/st24",
"/dev/st25", "/dev/st26", "/dev/st27", "/dev/st28", "/dev/st29",
"/dev/st30", "/dev/st31",
0,
};
kdev_t scsi_tape_devs[] =
{
0x0900, 0x0901, 0x0902, 0x0903, 0x0904, 0x0905, 0x0906, 0x0907,
0x0908, 0x0909, 0x090A, 0x090B, 0x090C, 0x090D, 0x090E, 0x090F,
0x0910, 0x0911, 0x0912, 0x0913, 0x0914, 0x0915, 0x0916, 0x0917,
0x0918, 0x0919, 0x091A, 0x091B, 0x091C, 0x091D, 0x091E, 0x091F,
0,
};
BYTE *ide_tape_handles[] =
{
"/dev/ht0", "/dev/ht1", "/dev/ht2", "/dev/ht3", "/dev/ht4",
"/dev/ht5", "/dev/ht6", "/dev/ht7", "/dev/ht8", "/dev/ht9",
"/dev/ht10", "/dev/ht11", "/dev/ht12", "/dev/ht13", "/dev/ht14",
"/dev/ht15", "/dev/ht16", "/dev/ht17", "/dev/ht18", "/dev/ht19",
"/dev/ht20", "/dev/ht21", "/dev/ht22", "/dev/ht23", "/dev/ht24",
"/dev/ht25", "/dev/ht26", "/dev/ht27", "/dev/ht28", "/dev/ht29",
"/dev/ht30", "/dev/ht31", 0
};
kdev_t ide_tape_devs[] =
{
0x3700, 0x3701, 0x3702, 0x3703, 0x3704, 0x3705, 0x3706, 0x3707,
0x3708, 0x3709, 0x370A, 0x370B, 0x370C, 0x370D, 0x370E, 0x370F,
0x3710, 0x3711, 0x3712, 0x3713, 0x3714, 0x3715, 0x3716, 0x3717,
0x3718, 0x3719, 0x371A, 0x371B, 0x371C, 0x371D, 0x371E, 0x371F,
0
};
ULONG max_scsi_tape_devs = sizeof(scsi_tape_devs) / sizeof(kdev_t);
ULONG max_ide_tape_devs = sizeof(ide_tape_devs) / sizeof(kdev_t);
ULONG max_scsi_tape_names = sizeof(scsi_tape_handles) / sizeof(BYTE *);
ULONG max_ide_tape_names = sizeof(ide_tape_handles) / sizeof(BYTE *);
void RemoveTapeDevices(void)
{
register ULONG j;
for (j=0; j < max_scsi_tape_names; j++)
{
if (SystemTape[j])
{
if (SystemTape[j]->filp)
filp_close(SystemTape[j]->filp, NULL);
TRXDRVFree(SystemTape[j]);
SystemTape[j] = 0;
}
}
}
void ScanTapeDevices(void)
{
register ULONG j;
for (j = 0; j < max_scsi_tape_names; j++)
{
if (!SystemTape[j])
{
if (!scsi_tape_devs[j])
break;
SystemTape[j] = (NWTAPE *) TRXDRVAlloc(sizeof(NWTAPE), NWTAPE_TAG);
if (!SystemTape[j])
{
TRXDRVPrint("trxdrv: memory alloc failure in AddTapeDevices\n");
continue;
}
TRXDRVSet(SystemTape[j],
3-Ware Raid driver fails to update GenDisk head
Andre/LKML, I am still working on this, but would appreciate some help from whomever owns this driver proper. I have discovered that the 3Ware drivers are not updating the gendisk_head with devices reported and exposed to user space as /dev/sda, sdb, etc. The adapter driver does correctly report devices to user space, but is not properly reflecting these devices in the gendisk_head, which makes it rather hard for kernel level drivers to scan and determine which devices are attached to the controller. I attempted to correct this in the code, but found that these changes are a very significant effort to get working. Please advise. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3-Ware Raid driver fails to update GenDisk head
On Mon, Apr 23, 2001 at 09:47:01PM +0200, Guest section DW wrote: > On Mon, Apr 23, 2001 at 12:08:52PM -0600, Jeff V. Merkey wrote: > > > > I am still working on this, but would appreciate some help from > > whomever owns this driver proper. I have discovered that the > > 3Ware drivers are not updating the gendisk_head with devices > > reported and exposed to user space as /dev/sda, sdb, etc. > > But that is the job of sd.c, not of a driver. These drivers are an IDE driver that simulates a SCSI interface. It reported IDE devices as SCSI handles, so there's some holes. I guess you were not aware of this, or you would have known that standard sd.c is not working. :-) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: filp_open() in 2.2.19 causes memory corruption
On Mon, Apr 23, 2001 at 10:24:55PM +0200, Manfred Spraul wrote: > Are you sure the trace is decoded correctly? > > > CPU:0 > > EIP:0010:[sys_mremap+31/884] > > EFLAGS: 00010206 > > > Code: ac ae 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 75 d9 > ac ae is > lodsb > scasb > > Could you run > #objdump --disassemble-all --reloc linux/mm/mremap.o | less > > and check that the code is really at offset 31 of sys_mremap? > > And is it correct that only 64 MB memory is installed/enabled? > > -- > Manfred Manfred, This is what's being reported when I produce the oops. I think we have memory corruption somewhere, which explains the funky code offsets. It's easy to reproduce. Call filp_open with the handle table I gave you on a single IDE system with **NO** tape drive in the system, and it crashes quite after the module is loaded the fisrt time, then unloaded, and reloaded a second time. The oops happens on the second insmod of the module. I can provide you the actual module itself built with all the code if you want to reproduce it. It's 100% reproduceable. Jeff > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3-Ware Raid driver fails to update GenDisk head
On Mon, Apr 23, 2001 at 11:13:12PM +0200, Guest section DW wrote: > On Mon, Apr 23, 2001 at 01:55:00PM -0600, Jeff V. Merkey wrote: > > On Mon, Apr 23, 2001 at 09:47:01PM +0200, Guest section DW wrote: > > > On Mon, Apr 23, 2001 at 12:08:52PM -0600, Jeff V. Merkey wrote: > > > > > > > > I am still working on this, but would appreciate some help from > > > > whomever owns this driver proper. I have discovered that the > > > > 3Ware drivers are not updating the gendisk_head with devices > > > > reported and exposed to user space as /dev/sda, sdb, etc. > > > > > > But that is the job of sd.c, not of a driver. > > > > These drivers are an IDE driver that simulates a SCSI interface. It > > reported IDE devices as SCSI handles, so there's some holes. I guess > > you were not aware of this, or you would have known that standard sd.c > > is not working. > > Just like ide-scsi.c you mean? No. They're not that clean and well organized, though they are rather clever adapters and are pretty cool. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: filp_open() in 2.2.19 causes memory corruption
On Mon, Apr 23, 2001 at 11:03:48PM +0100, David Woodhouse wrote: > > [EMAIL PROTECTED] said: > > Are you sure the trace is decoded correctly? > > > > CPU:0 > > > EIP:0010:[sys_mremap+31/884] > > Probably not. It looks like it was munged by klogd. Some distributions are > still shipping with klogd configured to destroy the original information on > the way to the log, without even making it do a sanity check that the > System.map it's using actually matches the current kernel. > > Jeff, please disable the broken klogd symbol munging and reproduce it, > running the oops through ksymoops manually. Ksymoops should have built-in > sanity checks on the System.map it tries to use. > > Also, please make sure you report this as a serious bug with the vendor of > whatever distribution you're running on this box. > David, I will comply and repost the oops. Jeff > -- > dwmw2 > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NWFS broken on 2.4.3 -- someone removed WRITERAW
Hey guys, Whomever removed WRITERAW has broken NWFS. WRITE requests call _refile_buffer() after the I/O request and take my locally created buffer heads and munge them back into the linux buffer cache, causing massive memory corruption in the system. These buffers don't belong in Linus' buffer cache, they are owned by my LRU and ll_rw_block should not be blindly filing them back into the buffer cache. Please put something back in to allow me to write without the buffer heads always getting filed into Linus' buffer cache. This has broken NWFS on 2.4.3 and above. As for using Linus' buffer cache, until you put in the ability to create logical block mapping instead of physical, I will not be able to use it. Hopefully, this will make it in 2.5. I have some folks trying to use this with 2.4.3 and they are dead in the water until this gets addressed. Thanks Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3-Ware Raid driver fails to update GenDisk head
On Tue, Apr 24, 2001 at 12:45:35AM +0200, Jens Axboe wrote: > On Mon, Apr 23 2001, Jeff V. Merkey wrote: > > On Mon, Apr 23, 2001 at 11:13:12PM +0200, Guest section DW wrote: > > > On Mon, Apr 23, 2001 at 01:55:00PM -0600, Jeff V. Merkey wrote: > > > > On Mon, Apr 23, 2001 at 09:47:01PM +0200, Guest section DW wrote: > > > > > On Mon, Apr 23, 2001 at 12:08:52PM -0600, Jeff V. Merkey wrote: > > > > > > > > > > > > I am still working on this, but would appreciate some help from > > > > > > whomever owns this driver proper. I have discovered that the > > > > > > 3Ware drivers are not updating the gendisk_head with devices > > > > > > reported and exposed to user space as /dev/sda, sdb, etc. > > > > > > > > > > But that is the job of sd.c, not of a driver. > > > > > > > > These drivers are an IDE driver that simulates a SCSI interface. It > > > > reported IDE devices as SCSI handles, so there's some holes. I guess > > > > you were not aware of this, or you would have known that standard sd.c > > > > is not working. > > > > > > Just like ide-scsi.c you mean? > > > > No. They're not that clean and well organized, though they are rather > > clever adapters and are pretty cool. > > Come on Jeff, what Andries is saying is that it _works_ like ide-scsi. > It registers itself as a SCSI hba like a "regular" SCSI card, hence it > uses the SCSI infrastructure -- alas, disks driven by sd.c OK, OK. I get it. Sorry for the digs :-) Jeff > > -- > Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NWFS broken on 2.4.3 -- someone removed WRITERAW
On Tue, Apr 24, 2001 at 12:58:09AM +0200, Jens Axboe wrote: > On Mon, Apr 23 2001, Jeff V. Merkey wrote: > > > > > > Hey guys, > > > > Whomever removed WRITERAW has broken NWFS. WRITE requests call > > _refile_buffer() after the I/O request and take my locally created > > buffer heads and munge them back into the linux buffer cache, causing > > massive memory corruption in the system. These buffers don't belong > > in Linus' buffer cache, they are owned by my LRU and ll_rw_block > > should not be blindly filing them back into the buffer cache. > > > > Please put something back in to allow me to write without the buffer > > heads always getting filed into Linus' buffer cache. This has > > broken NWFS on 2.4.3 and above. > > bh->b_end_io = my_end_io_handler; > submit_bh(WRITE, bh); Jens, Bless you. I'll code the fix, test it, and get it out. Jeff > > Be a happy camper. > > -- > Jens Axboe > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: partition table: chs question
Please also check vger.timpanogas.org/nwfs/nwfs.tar.gz:disk.c for NetWare specific calculations of the CHS values, a different method is used for NetWare partitions vs. everything else (Novell just had to be different). If you do not use their methods on NetWare partitions, NetWare will not recognize the partition entries correctly, and will attempt to reinitialize the entire partition table on a system if they are wrong (Ouch!). NetWare does a different calculation for conversion of cylinder values above 1024. Jeff - Original Message - From: "Guest section DW" <[EMAIL PROTECTED]> To: "Andreas Jellinghaus" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, February 25, 2001 2:47 PM Subject: Re: partition table: chs question > On Sun, Feb 25, 2001 at 04:35:34PM +0100, Andreas Jellinghaus wrote: > > > for partitions not in the first 8gb of a harddisk, what > > should the c/h/s start and end value be ? > > > > most fdisks seem to set start and end to 255/63/1023. > > but partition magic creates partitions with start set to > > 0/1/1023 and end set to 255/63/1023, and detects a problem > > if start is set to 255/63/1023. > > > > so, how should a partition table look like ? > > Since these values will never be used you can imagine that they > are not of great interest. Do whatever you like. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: partition table: chs question
- Original Message - From: "Jeff V. Merkey" <[EMAIL PROTECTED]> To: "Guest section DW" <[EMAIL PROTECTED]>; "Andreas Jellinghaus" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, February 25, 2001 5:02 PM Subject: Re: partition table: chs question > > Please also check vger.timpanogas.org/nwfs/nwfs.tar.gz:disk.c for NetWare > specific calculations of the CHS values, a different method is used for > NetWare partitions vs. everything else (Novell just had to be different). > If you do not use their methods on NetWare partitions, NetWare will not > recognize the partition entries correctly, and will attempt to reinitialize > the entire partition table on a system if they are wrong (Ouch!). NetWare > does a different calculation for conversion of cylinder values above 1024. > > Jeff > > > - Original Message - > From: "Guest section DW" <[EMAIL PROTECTED]> > To: "Andreas Jellinghaus" <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]> > Sent: Sunday, February 25, 2001 2:47 PM > Subject: Re: partition table: chs question > > > > On Sun, Feb 25, 2001 at 04:35:34PM +0100, Andreas Jellinghaus wrote: > > > > > for partitions not in the first 8gb of a harddisk, what > > > should the c/h/s start and end value be ? > > > > > > most fdisks seem to set start and end to 255/63/1023. > > > but partition magic creates partitions with start set to > > > 0/1/1023 and end set to 255/63/1023, and detects a problem > > > if start is set to 255/63/1023. > > > > > > so, how should a partition table look like ? > > > > Since these values will never be used you can imagine that they > > are not of great interest. Do whatever you like. This statement is not true of NetWare partitions. They are used to validate whether or not the partition table has been corrupted. Jeff > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: partition table: chs question
On Mon, Feb 26, 2001 at 04:11:56AM +0100, Guest section DW wrote: > On Sun, Feb 25, 2001 at 05:02:09PM -0700, Jeff V. Merkey wrote: > > > Please also check vger.timpanogas.org/nwfs/nwfs.tar.gz:disk.c for NetWare > > specific calculations of the CHS values, a different method is used for > > NetWare partitions vs. everything else (Novell just had to be different). > > > > On Sun, Feb 25, 2001 at 04:35:34PM +0100, Andreas Jellinghaus wrote: > > > > > > > for partitions not in the first 8gb of a harddisk, what > > > > should the c/h/s start and end value be ? > > > > > > > > most fdisks seem to set start and end to 255/63/1023. > > > > but partition magic creates partitions with start set to > > > > 0/1/1023 and end set to 255/63/1023, and detects a problem > > > > if start is set to 255/63/1023. > > Good. I added this to > http://www.win.tue.nl/~aeb/partitions/partition_types-2.html#above1024chs > > Now that I looked at this disk.c anyway: it has a table of > partition types, and it seems I collect these. > (See http://www.win.tue.nl/~aeb/partitions/partition_types-1.html ) > Are types 57 and 77, labeled "VNDI Partition", actually in use? No. They are not. 65, and 77 are the ones in use. Novell was using 67 for Wolf Mountain, but for NSS, they are exclusively using "69" (I know who at Novell picked this number, and I'll give you three guesses what is always on his mind). Jeff > > Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: partition table: chs question
On Sun, Feb 25, 2001 at 05:59:33PM -0800, Andre Hedrick wrote: > > > It does not matter because the usage of CHS will dies soon because it was > voted to death in Austin last week. There will only be LBA addressing > from now on out. If someone has Linux and NetWare dual booted on a system, and does not fill out the CHS fields properly for NetWare partitions, When NetWare boots, it will wipe the partition table (it will ask you first) and will not recognize any of the partitions. It does this because if it sees CHS values it does not expect, it assumes the partition table has been corrupted. Jeff > > On Sun, 25 Feb 2001, Jeff V. Merkey wrote: > > > > > Please also check vger.timpanogas.org/nwfs/nwfs.tar.gz:disk.c for NetWare > > specific calculations of the CHS values, a different method is used for > > NetWare partitions vs. everything else (Novell just had to be different). > > If you do not use their methods on NetWare partitions, NetWare will not > > recognize the partition entries correctly, and will attempt to reinitialize > > the entire partition table on a system if they are wrong (Ouch!). NetWare > > does a different calculation for conversion of cylinder values above 1024. > > > > Jeff > > > > > > - Original Message - > > From: "Guest section DW" <[EMAIL PROTECTED]> > > To: "Andreas Jellinghaus" <[EMAIL PROTECTED]>; > > <[EMAIL PROTECTED]> > > Sent: Sunday, February 25, 2001 2:47 PM > > Subject: Re: partition table: chs question > > > > > > > On Sun, Feb 25, 2001 at 04:35:34PM +0100, Andreas Jellinghaus wrote: > > > > > > > for partitions not in the first 8gb of a harddisk, what > > > > should the c/h/s start and end value be ? > > > > > > > > most fdisks seem to set start and end to 255/63/1023. > > > > but partition magic creates partitions with start set to > > > > 0/1/1023 and end set to 255/63/1023, and detects a problem > > > > if start is set to 255/63/1023. > > > > > > > > so, how should a partition table look like ? > > > > > > Since these values will never be used you can imagine that they > > > are not of great interest. Do whatever you like. > > > - > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > > the body of a message to [EMAIL PROTECTED] > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > Please read the FAQ at http://www.tux.org/lkml/ > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > > > Andre Hedrick > Linux ATA Development > ASL Kernel Development > - > ASL, Inc. Toll free: 1-877-ASL-3535 > 1757 Houret Court Fax: 1-408-941-2071 > Milpitas, CA 95035Web: www.aslab.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: partition table: chs question
- Original Message - From: "Andre Hedrick" <[EMAIL PROTECTED]> To: "Jeff V. Merkey" <[EMAIL PROTECTED]> Cc: "Jeff V. Merkey" <[EMAIL PROTECTED]>; "Guest section DW" <[EMAIL PROTECTED]>; "Andreas Jellinghaus" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, February 26, 2001 10:32 AM Subject: Re: partition table: chs question > On Mon, 26 Feb 2001, Jeff V. Merkey wrote: > > > On Sun, Feb 25, 2001 at 05:59:33PM -0800, Andre Hedrick wrote: > > > > > > > > > It does not matter because the usage of CHS will dies soon because it was > > > voted to death in Austin last week. There will only be LBA addressing > > > from now on out. > > > > If someone has Linux and NetWare dual booted on a system, and does not > > fill out the CHS fields properly for NetWare partitions, When NetWare > > boots, it will wipe the partition table (it will ask you first) and > > will not recognize any of the partitions. It does this because if it > > sees CHS values it does not expect, it assumes the partition table > > has been corrupted. > > Then Netware is a bad HOST-Driver and people should expect to be hurt by > using a HOST that is not compliant. It is the responsiblity of the user > to tell the HOST-OS what it needs to do. Especially if one of the OSes > can not be intelligent enough to adpat to the changes. Andre, I am not going to debate whether what they do is good or bad, there's arguments either way for the value in being able to detect a corrupted boot sector. Unfortunately, this is how all the installed NetWare versions on planet Earth behave. If someone is rearranging a partition table and fills out these values wrong, it will make the drive unreadable to NetWare, and make it look like Linux just corrupted the drive (since Linux will get blamed). The disk tools should observe each OS's weirdness if it may potentially change values in this table and cause data loss. Jeff > > Regards, > > Andre Hedrick > Linux ATA Development > ASL Kernel Development > -- --- > ASL, Inc. Toll free: 1-877-ASL-3535 > 1757 Houret Court Fax: 1-408-941-2071 > Milpitas, CA 95035Web: www.aslab.com > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: partition table: chs question
- Original Message - From: "Guest section DW" <[EMAIL PROTECTED]> To: "Jeff V. Merkey" <[EMAIL PROTECTED]> Cc: "Jeff V. Merkey" <[EMAIL PROTECTED]>; "Andreas Jellinghaus" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, February 26, 2001 1:11 PM Subject: Re: partition table: chs question > On Mon, Feb 26, 2001 at 11:24:07AM -0700, Jeff V. Merkey wrote: > > On Mon, Feb 26, 2001 at 04:11:56AM +0100, Guest section DW wrote: > > > > (See http://www.win.tue.nl/~aeb/partitions/partition_types-1.html ) > > > Are types 57 and 77, labeled "VNDI Partition", actually in use? > > > > No. They are not. 65, and 77 are the ones in use. Novell was using > > 67 for Wolf Mountain, but for NSS, they are exclusively using 69. > > Wait! 57 and 77 are not in use, but 65 and 77 are? > (Is the second 77 a typo for 66 or 67?) > > A lot of partition IDs are attributed to Novell. > 64 (Netware 286) and 65 (Netware 386) are well established, and > you tell me 66 is Netware SMS, 67 is Wolf Mountain and 69 is Netware NSS. > But also 51 and 68 occur in reports. Do you know anything about those? Novell is assigned block 60-70 by some committee way back in the mid-1980's. 51 is not legal for them, I would like to look at this one. Any numbers in range 60-70 they can and do use, though most are experimental. 66 and 64 are no longer used, but older stuff may use them. 77 is one we are using internally for M2FS/M2CS partitions. VNDI can be dropped. :-) Jeff > > Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] PCI-SCI Drivers 1.2-2 reposted
I have reposted the PCI-SCI files since some folks have reported corruption in one of the files on our server. These drivers support PCI-SCI hardware versions up to the PSB66. These drivers can be downloaded for 2.2 and 2.4 Linux at vger.timpanogas.org:/sci/pci-sci-1.2-2 via ftp or from www.ute-linux.org No new bugs have been reported for these drivers, this is a reposting. If you ran into any problems with a previous version of these drivers, you may want to download them again. Jeff Merkey Chief Engineer, TRG - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NetWare Changing IP Port 524
Petr/Linux, If you are relying on port 524 to get SAP information for NCPFS over TCPIP, you may want to track this since it appears Novell will be patching this port to close a security flaw. I added the tracking URL so you can review what changes they are proposing. I think what they are proposing as an immediate patch may break NCPFS -- you will need to check. :-) Jeff Novell NetWare discloses system information Novell's NetWare operating system contains a flaw that allows system information to be leaked via TCP port 524 in pure IP configurations. When NetWare is used in a mix Microsoft environment, the Novell operating system leaks data via Service Advertising Protocol (SAP). Other third-party applications compound the problem as well. A hacker can use the data to gain knowledge on the inner workings of the affected system. It is recommended that port 524 be blocked to prevent any leaks. For more information on SAP: http://support.novell.com/cgi-bin/search/search.pl?database_name=kb&type=HTM L&docid=%03%21F221133%3a973867389%3a%20%28%2010050864%20%29%20%20%07%01%00&b yte_count=71624 ** - 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: NetWare Changing IP Port 524
Petr Vandrovec wrote: > > On 14 Nov 00 at 12:11, Jeff V. Merkey wrote: > > > If you are relying on port 524 to get SAP information for NCPFS over > > TCPIP, you may want to track this since it appears Novell will be > > patching this port to close a security flaw. I > > added the tracking URL so you can review what changes they are > > proposing. I think what they > > are proposing as an immediate patch may break NCPFS -- you will need to > > check. > > I think that it is unavoidable. Either you can browse network resources, > through SAP, NDS, DNS, SLP, bindery - and you also disclose > informations - or you cannot browse network and users will get angry > from typing 80 characters FQDN names... > > You can limit it by removing [Search] right for [Public] from your NDS - > and I believe that it is only correct solution. Of course every NDS server > must be able to tell to [public] address of at least one other server > nearest to [root], as client must be able to find where r/w replica > resides - and because of you know that there is [root] object in every > tree, you can find also [root] owner IP/IPX address. But if even knowing > of address of server can kill your network, you should already firewall > everything out. > > > Novell's NetWare operating system contains a flaw that allows > > system information to be leaked via TCP port 524 in pure IP > > configurations. When NetWare is used in a mix Microsoft > > environment, the Novell operating system leaks data via Service > > Advertising Protocol (SAP). Other third-party applications > > compound the problem as well. A hacker can use the data to gain > > knowledge on the inner workings of the affected system. It is > > recommended that port 524 be blocked to prevent any leaks. > > Yeah. They forgot to note that after blocking port 524 nobody > can connect to server from outer world. They could say in less > words that Netware and IP are not on same boat ;-) I think they > should fix buffer overflows and possible abends in their NCP engine, > and issue warnings about not giving [Search] rights to [Public] > instead of blocking whole world from Netware servers. Hopefully, sanity will rule out here. I information being leaked from what I reviewed was the ability for a hacker to exploit port 524 and use it to obtain a local copy of the entire routing table for other IP servers INSIDE an organization (which is a huge hole). Jeff > > BTW, in our tree not-logged-in object does not see anything, except > few objects which have explicitly granted visibility for [public]. > But maybe that I misunderstood their information... If they are > talking about that information learned through SLP/SAP/NDS are > available through SLP/SAP/NDS, I do not see anything wrong with it. > If hacker can ask this server, it could also ask directly to source > of that information, unless your server is also serving as firewall > (and if it is, you should visit filtering section in FILTCFG.NLM...) > 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/ - 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: NetWare Changing IP Port 524
Gregory Maxwell wrote: > > On Tue, Nov 14, 2000 at 01:29:31PM -0700, Jeff V. Merkey wrote: > > Hopefully, sanity will rule out here. I information being leaked from > > what I reviewed was the ability for a hacker to exploit port 524 and use > > it > > to obtain a local copy of the entire routing table for other IP servers > > INSIDE an organization (which is a huge hole). > > That is obviously the hole as it is clearly not the intended function of the > service. However, anyone who depends on the secrecy of their IP routing > tables or overall network topology for security has bigger problems then > some stupid Netware bug. Greg, The TCPIP implementation of NCP is little more than the existing RIP/SAP and NCP protocols enveloped inside of UDP/SLP. The problem has nothing to do with IP routing, but the ability to send envoloped RIP/SAP requests into port 524, and getting a complete topology description of the other side of a NetWare server being used as a firewall. It would be kind of like opening a port on Linux, then letting people come into the server with root file read/write and letting them read the network topology on the other side. What's nasty about this problem is that it would give any internet hackers the ability to discover the network topology (including which servers host NDS master and replica databases). Not very secure. The concern for Petr is if in fixing this hole, Novell breaks features Petr needs. I doubt they can change it at this point, other than allow firewall servers to turn it off to the external world. As Petr pointed out, closing this port will break all the clients, including theirs. To make a change of this magnitude would require they rev their clients and servers (and break access to the entire installed base). I provided Petr the URL so he can track what changes they post. You misunderstood, I think. 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/
NCPFS not returning Volume Size (???)
Petr,
NCPFS in 2.2.18-pre21 is not returning volume size via df -h. I checked
your code and found this comment:
static int ncp_statfs(struct super_block *sb, struct statfs *buf, int bufsiz)
{
struct statfs tmp;
/* We cannot say how much disk space is left on a mounted
NetWare Server, because free space is distributed over
volumes, and the current user might have disk quotas. So
free space is not that simple to determine. Our decision
here is to err conservatively. */
tmp.f_type = NCP_SUPER_MAGIC;
tmp.f_bsize = 512;
tmp.f_blocks = 0;
tmp.f_bfree = 0;
tmp.f_bavail = 0;
tmp.f_files = -1;
tmp.f_ffree = -1;
tmp.f_namelen = 12;
return copy_to_user(buf, &tmp, bufsiz) ? -EFAULT : 0;
}
NCP Code
/17E6 Get Object's Remaining Disk Space
(I have docs on this one and can send if you need it).
will return in NetWare sized blocks the space remaining for this
user (which will be the user ID used to login). The fact that quota's
are present for a user (user space restriction node -- in NWDIR.H)
should be irrelevant, since from the view of a Linux client attached to
a NetWare server, this is their assigned storage.
This NCP also speaks in hardcoded blocksizes of 4096 bytes, so that's
the factor for free space for whatever login ID was used to mount
the NetWare Volume that can be used in ncpfs_statfs() to return
free space.
I have not gone through your userspace code as of yet, but to make
this work, you need the ObjectID for the User Account you used to
connect to the server in order to make this work.
I noticed I could not get free space from my Server with NCPFS with
df -h, and tracked it down. Several NetWare customers migrating
installations of NetWare to Linux pointed it out when they were
moving Oracle databases over to Linux from NetWare.
I noticed that 2.4 also is not reporting Volume free space.
The current NCPFS code, like a lot of Linux code, is structured
in a manner that's very different from Novell's internal code,
(the names are shorter for one, which is an improvement). The
way the NCP codes are peeled off is different and not the
large case and switch structure employed in NetWare, so it's
a little hard for me to follow since I am used to NCPs being
grouped into case/switch classes. If you can point me to
where 1) the login ID is stored and B) where NCP packet
request/reponse headers are constructed, i.e. a skeleton
to send/receive the requests I can grab, I'll try to
code this for you.
:-)
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/
Re: test11-pre6
On Thu, Nov 16, 2000 at 06:33:11PM -0800, Linus Torvalds wrote: > > The log-file says it all.. > > Linus > > - > > - pre6: > - Intel: start to add Pentium IV specific stuff (128-byte cacheline > etc) > - David Miller: search-and-destroy places that forget to mark us > running after removing us from a wait-queue. Level I > - me: NFS client write-back ref-counting SMP instability. > - me: fix up non-exclusive waiters > - Trond Myklebust: Be more careful about SMP in NFS and RPC code > - Trond Myklebust: inode attribute update race fix > - Charles White: don't do unaligned accesses in cpqarray driver. > - Jeff Garzik: continued driver cleanup and fixes > - Peter Anvin: integrate more of the Intel patches. > - Robert Love: add i815 signature to the intel AGP support > - Rik Faith: DRM update to make it easier to sync up 2.2.x > - David Woodhouse: make old 16-bit pcmcia controllers work > again (ie i82365 and TCIC) Level I The list is getting shorter. Jeff > > - pre5: > - Rasmus Andersen: add proper "" for sound drivers > - David Miller: sparc64 and networking updates > - David Trcka: MOXA numbering starts from 0, not 1. > - Jeff Garzik: sysctl.h standalone > - Dag Brattli: IrDA finishing touches > - Randy Dunlap: USB fixes > - Gerd Knorr: big bttv update > - Peter Anvin: x86 capabilities cleanup > - Stephen Rothwell: apm initcall fix - smp poweroff should work > - Andrew Morton: setscheduler() spinlock ordering fix > - Stephen Rothwell: directory notification documentation > - Petr Vandrovec: ncpfs capabilities check cleanup > - David Woodhouse: fix jffs to use generic is() library > - Chris Swiedler: oom_kill selection fix > - Jens Axboe: re-merge after sleeping in ll_rw_block. > - Randy Dunlap: USB updates (pegasus and ftdi_sio) > - Kai Germaschewski: ISDN ppp header compression fixed > > - pre4: > - Andrea Arcangeli: SMP scheduler memory barrier fixup > - Richard Henderson: fix alpha semaphores and spinlock bugs. > - Richard Henderson: clean up the file from hell: "xor.c" > > - pre3: > - James Simmons: vgacon "printk()" deadlock with global irq lock. > - don't poke blanked console on console output > - Ching-Ling: get channels right on ALI audio driver > - Dag Brattli and Jean Tourrilhes: big IrDA update > - Paul Mackerras: PPC updates > - Randy Dunlap: USB ID table support, LEDs with usbkbd, belkin > serial converter. > - Jeff Garzik: pcnet32 and lance net driver fix/cleanup > - Mikael Pettersson: clean up x86 ELF_PLATFORM > - Bartlomiej Zolnierkiewicz: sound and drm driver init fixes and > cleanups > - Al Viro: Jeff missed some kmap()'s. sysctl cleanup > - Kai Germaschewski: ISDN updates > - Alan Cox: SCSI driver NULL ptr checks > - David Miller: networking updates, exclusive waitqueues nest properly, > SMP i_shared_lock/page_table_lock lock order fix. > > - pre2: > - Stephen Rothwell: directory notify could return with the lock held > - Richard Henderson: CLOCKS_PER_SEC on alpha. > - Jeff Garzik: ramfs and highmem: kmap() the page to clear it > - Asit Mallick: enable the APIC in the official order > - Neil Brown: avoid rd deadlock on io_request_lock by using a > private rd-request function. This also avoids unnecessary > request merging at this level. > - Ben LaHaise: vmalloc threadign and overflow fix > - Randy Dunlap: USB updates (plusb driver). PCI cacheline size. > - Neil Brown: fix a raid1 on top of lvm bug that crept in in pre1 > - Alan Cox: various (Athlon mmx copy, NULL ptr checks for > scsi_register etc). > - Al Viro: fix /proc permission check security hole. > - Can-Ru Yeou: SiS301 fbcon driver > - Andrew Morton: NMI oopser and kernel page fault punch through > both console_lock and timerlist_lock to make sure it prints out.. > - Jeff Garzik: clean up "kmap()" return type (it returns a kernel > virtual address, ie a "void *"). > - Jeff Garzik: network driver docs, various one-liners. > - David Miller: add generic "special" flag to page flags, to be > used by architectures as they see fit. Like keeping track of > cache coherency issues. > - David Miller: sparc64 updates, make sparc32 boot again > - Davdi Millner: spel "synchronous" correctly > - David Miller: networking - fix some bridge issues, and correct > IPv6 sysctl entries. > - Dan Aloni: make fork.c use proper macro rather than doing > get_exec_domain() by hand. > > - pre1: > - me: make PCMCIA work even in the absense of PCI irq's > - me: add irq mapping capabilities for Cyrix southbridges > - me: make IBMMCA compile right as a module > - me: uhhuh. Major atomic-PTE SMP race boo-boo. Fixed. > - Andrea Arkangeli: don't allow people to
Re: NCPFS not returning Volume Size (???)
On Thu, Nov 16, 2000 at 08:40:29PM -0700, Jeff V. Merkey wrote:
> Petr,
>
> NCPFS in 2.2.18-pre21 is not returning volume size via df -h. I checked
> your code and found this comment:
>
> static int ncp_statfs(struct super_block *sb, struct statfs *buf, int bufsiz)
> {
> struct statfs tmp;
>
> /* We cannot say how much disk space is left on a mounted
> NetWare Server, because free space is distributed over
> volumes, and the current user might have disk quotas. So
> free space is not that simple to determine. Our decision
> here is to err conservatively. */
>
> tmp.f_type = NCP_SUPER_MAGIC;
> tmp.f_bsize = 512;
> tmp.f_blocks = 0;
> tmp.f_bfree = 0;
> tmp.f_bavail = 0;
> tmp.f_files = -1;
> tmp.f_ffree = -1;
> tmp.f_namelen = 12;
> return copy_to_user(buf, &tmp, bufsiz) ? -EFAULT : 0;
> }
>
> NCP Code
>
> /17E6 Get Object's Remaining Disk Space
>
> (I have docs on this one and can send if you need it).
>
> will return in NetWare sized blocks the space remaining for this
> user (which will be the user ID used to login). The fact that quota's
> are present for a user (user space restriction node -- in NWDIR.H)
> should be irrelevant, since from the view of a Linux client attached to
> a NetWare server, this is their assigned storage.
>
> This NCP also speaks in hardcoded blocksizes of 4096 bytes, so that's
> the factor for free space for whatever login ID was used to mount
> the NetWare Volume that can be used in ncpfs_statfs() to return
> free space.
COrrection. 3.x always reports as 4096 blocks, 4.11 > reports as
4K, 8K, 16K, 32K, and 64K. I have not checked what NSS is reporting,
but will test tonight.
Jeff
>
> I have not gone through your userspace code as of yet, but to make
> this work, you need the ObjectID for the User Account you used to
> connect to the server in order to make this work.
>
> I noticed I could not get free space from my Server with NCPFS with
> df -h, and tracked it down. Several NetWare customers migrating
> installations of NetWare to Linux pointed it out when they were
> moving Oracle databases over to Linux from NetWare.
>
> I noticed that 2.4 also is not reporting Volume free space.
>
> The current NCPFS code, like a lot of Linux code, is structured
> in a manner that's very different from Novell's internal code,
> (the names are shorter for one, which is an improvement). The
> way the NCP codes are peeled off is different and not the
> large case and switch structure employed in NetWare, so it's
> a little hard for me to follow since I am used to NCPs being
> grouped into case/switch classes. If you can point me to
> where 1) the login ID is stored and B) where NCP packet
> request/reponse headers are constructed, i.e. a skeleton
> to send/receive the requests I can grab, I'll try to
> code this for you.
>
> :-)
>
> 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/
MANOS/Ring 0 Linux lists back up
Now that sendmail/load average problems have been nailed for 2.2.18> 2.4, the mailing lists are working. We apologize, but the server was upgraded and during the upgrade, most folks addresses got zapped in the var/lib/majordomo/lists directory, so folks who want to track Andre and our work on the ring 0 Linux on the MANOS kernel will need to sign back up at [EMAIL PROTECTED] again. As much as this has happened in the past on LKML, everyone is probably used to ir already anyway. Thanks, 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/
Re: test11-pre6
On Fri, Nov 17, 2000 at 12:30:46AM -0700, Erik Andersen wrote: > On Thu Nov 16, 2000 at 08:45:10PM -0700, Jeff V. Merkey wrote: > > > > > > - pre6: > > > - Intel: start to add Pentium IV specific stuff (128-byte cacheline > > > etc) > > > - David Miller: search-and-destroy places that forget to mark us > > > running after removing us from a wait-queue. > > Level I > > > - me: NFS client write-back ref-counting SMP instability. > > > - me: fix up non-exclusive waiters > > > - Trond Myklebust: Be more careful about SMP in NFS and RPC code > > > - Trond Myklebust: inode attribute update race fix > > > - Charles White: don't do unaligned accesses in cpqarray driver. > > > - Jeff Garzik: continued driver cleanup and fixes > > > - Peter Anvin: integrate more of the Intel patches. > > > - Robert Love: add i815 signature to the intel AGP support > > > - Rik Faith: DRM update to make it easier to sync up 2.2.x > > > - David Woodhouse: make old 16-bit pcmcia controllers work > > > again (ie i82365 and TCIC) > > Level I > > > > The list is getting shorter. > > WTF is "Level I" supposed to mean and why have you inserted it seemingly > randomly into the changelog and why are you telling the world about it? I've > seen you do this several times and I am completely baffled. Surely you have > some reason for wanting to share? NetWare was delineated into five levels of bugs to determine commercial ship worthiness. NT is somewhat sloppier than what Novell does because they are not running a ring 0 OS. Kernel development is Ring 0 development, so a lot of the same concepts apply: Level I - Abends and Severe Kernel or Memory Corruption bugs, or functionality bugs. (Oops level stuff, or Deadlock types of bugs). Level II - Critical Bugs in peripheral subsystems, like broken drivers that would abend (Oops), but that would not halt shipment of core components. Level III - boundry condition bugs, like app or subsystem problems in low memory, intermittent LAN or obscure hardware related bugs. Level IV - Missing Functionality, like the speaker volume not working with pcmcia-cs-3.1.22 on an IBM thinkpad -- non-critical, but annoying. Level V - Feature/Documentation out of sync, docs need updating, etc. Where I came from, when you ht 0 Level I bugs, time to ship. When Linus can post a 2.4 status that has no new Level I issues, I will put my 2.4 RPM out. To date, i just keeps dragging on, with a whole new slew of new Level I bugs every week, but it is having fewer and fewer of them. He obviously posts these updates for public comment. We ship Linux, so there's our 2 cents. Jeff > > -Erik > > -- > Erik B. Andersen email: [EMAIL PROTECTED] > --This message was written using 73% post-consumer electrons-- - 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: ORACLE and 2.4-test10
Alan, When we ported Oracle to NetWare, we found that making changes to the core file systems in NetWare that Oracle needed would tank FS performance, so we came up with something called direct FS, a separate File System interface just for Oracle. The SOSD layer inside of Oracle allows them, via simple config statements, to redirect to different file systems, even specialized ones, so this is trivial for them to instrument. The whole O_SYNC thing accross the entire OS could be problematic to support. In NetWare, directFS was little more than a "raw" interface that bypassed the file cache. It would be like having an API to a direct physical file system that never cached data in the buffer cache. In Linux, this may be tough to pull off, but Al Viro could instrument a raw_read, raw_write function table entry that would do something similiar that would allow Oracle to detect if an FS had a raw mode, since this is what they actually need. My 2 cents anyway. 8) Jeff Alan Cox wrote: > > > Can anybody on tell me whatever there are still > > serious pitfalls in running Oracle-8.1.6.1R2 on the > > Yes. > > > If I rememeber correctly there where some problems with > > SHM handling still left to resolve... > > SHM is resolved but O_SYNC is not yet fixed. You could therefore easily lose > your entire database > > - > 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: ORACLE and 2.4-test10
Alan Cox wrote: > > > performance, so we came up with something called direct FS, a separate > > File System interface just for Oracle. The SOSD layer inside of Oracle > > Yeah but you see thats ugly > > > In NetWare, directFS was little more than a "raw" interface that > > bypassed the file cache. It would be like having an API to a direct > > physical file system that never cached data in the buffer cache. In > > Its called O_DIRECT and kiovecs. Its already there. Much more generic than > an 'oraclefs' Then they should have what they need. If they have an SOSD plugin, no reason it shouldn't run. 8) Jeff > > 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/ - 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/
VFS Kernel Panic in 2.4.0-10(11)
This is probably a configuration mismatch of some kind, but I just finished building my 2.4.0 RPM skeletons and am installting them from our latest CD burn, and I am seeing the following problem when I upgrade our 2.2.17 kernel versions with 2.4.0-test10, then reboot them under 2.4: request_module[block-major-3]: Root fs not mounted VFS cannot open root device "301" or 03:01 Please append a correct "root=" boot option Kernel panic: VFS: Unable to mount root fs on 03:01. The system was running Ute-Linux under 2.2.17 then was upgraded to 2.4.0-10 (with IPVS and pre-11 patches). The disk is a 20GB device with /dev/hda1Linux (/,/boot) at 3,1 /dev/hda2Extended (contains a swap partition /dev/hda5) at 3,2 /dev/hda3Linux (/usr) at 3,3 /dev/hda4Linux (/archive) at 3,4 /dev/hda5Swap Swap at 3,5 Lilo is configured in linear mode. The device it's complaining about is present (03:01) and lilo does append a root=/dev/hda1 statement. Any ideas? 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/
Re: VFS Kernel Panic in 2.4.0-10(11)
We dfound it. 2.2.X .configs are incompatible with 2.4.0 and the upgrade RPMs sucked them in. Since IDE is a unique CONFIG option, this will break. Jeff "Jeff V. Merkey" wrote: > > > This is probably a configuration mismatch of some kind, but I just > finished building my 2.4.0 RPM skeletons and am installting them from > our latest CD burn, and I am seeing the following > problem when I upgrade our 2.2.17 kernel versions with 2.4.0-test10, > then reboot them under 2.4: > > request_module[block-major-3]: Root fs not mounted > VFS cannot open root device "301" or 03:01 > Please append a correct "root=" boot option > Kernel panic: VFS: Unable to mount root fs on 03:01. > > The system was running Ute-Linux under 2.2.17 then was upgraded to > 2.4.0-10 (with IPVS and pre-11 patches). > The disk is a 20GB device with > > /dev/hda1Linux (/,/boot) at > 3,1 > /dev/hda2Extended (contains a swap partition /dev/hda5) at > 3,2 > /dev/hda3Linux (/usr) at > 3,3 > /dev/hda4Linux (/archive) at > 3,4 > /dev/hda5Swap Swap at > 3,5 > > Lilo is configured in linear mode. The device it's complaining about is > present > (03:01) and lilo does append a root=/dev/hda1 statement. > > Any ideas? > > 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: Linux 2.2.18pre22
On Sun, Nov 19, 2000 at 01:11:33AM +, Alan Cox wrote: > > Bugs to go: PS/2 mouse detection > > Anything which isnt a strict bug fix or previously agreed is now 2.2.19 > material. > > Alan > > 2.2.18pre22 > o Fix HZ assumption in USB hub driver (Oleg Drokin) > o Fix ndisc range check on ipv6 (Dave Miller) > o Clear other fields in qcam VIDIOCGWIN return(Damion de Soto) > o Fix sparc64 includes for socket.h (Solar Designer) > o ELF platform was misset for Pentium IV (Mikael Pettersson) > o ADMTek 985 ident was wrong (Lee Bradshaw) > o Fix filemark status test on scsi tape (Robin Miller) > o Fix file/block when spacing to tape beginning (Kai Maiksara) > o Small ISDN documentation fixes (Kai Germaschewski) Alan, On the ISDN issue, isdn4K-utils seems to be out of sync with kernels older than 2.2.16. Some #define's that used to be in the 2.2.14 patch don't seem to be in 2.2.17 >. At present, requires an ugly .config patch to work under 2.2.18-21. Jeff > o Resync icn driver with core isdn tree (Kai Germaschewski) > o Fix isdn loopback driver(Kai Germaschewski) > o Fix small leaks in lockd(Trond Myklebust) > o Add Pentium IV rep nop, ident etc (Various folks, >notably HPA and >Linda Wang) > o Update sparc default config (Dave Miller) > o Hopefully properly fix the megaraid problem (Willy Tarreau, AMI >and others) > o Resync tcp bits with Dave (Dave Miller) > o Make cpqarray provide randomness(Nigel Metheringham) > o Fix wavefront symbols bug (Carlos E. Gorges) > o Fix acenic jumbo handling when flushing ring(Val Hensson) > o Fix ace_set_mac_addr for littleendian hosts (Stephen Hack) > o Fix assorted typos in the kernel(Andries Brouwer) > o EEPro100 fixes (Dragan Stancevic) > o Fix hisax _setup crash case (David Woodhouse) > o Fix small cdrom driver bugs (Jens Axboe) > o Fix remaining vmalloc corner cases (Ben LaHaise) > o Update USB maintainers (Greg Kroah-Hartman) > o Fix matroxfb doc bug(Pavel Rabel) > o Fix setscheduler lock inversion (Andrew Morton) > o Fix scsi unload/sg ioctl oops (Paul Clements) > > 2.2.18pre21 > o Environment controller update for sparc (Eric Brower) > o No italian translation for config.help (Andrea Ferraris) > o Fix type error in buz driver(Pete Zaitcev) > o Resnchronize Apple PowerMac codebase(Paul Mackerras & co) > o Merge powermac tree fixes into usb > o Powermac input device handling changes > o Fix console switch fonts > o S/390 merge (IBM S/390 folks) > (Merge grunt work done by Kurt Roeckx) > o Make knfsd TCP an option(me) > o Drop cisco info packets (0x2000)(Ivan Passos) > o Add belkin USB serial cable (William Greathouse) > > 2.2.18pre20 > o Fix ide-probe SMP build error (Ian Morgan) > o Fix appletalk physical layer ioctl handling (Andi Kleen) > o Sparc update(Dave Miller) > o Update Stephen Tweedie's contact info (Stephen Tweedie) > o Fix typo in esp and scsi_obsolete code (Dave Miller) > o Bonding ioctl check fix (Willy Tarreau) > o Fix ipv6 procfs bug (Al Viro) > o Report PIV in proc as family 15 and uname as(me) > model 6 as discussed > o Redo Intel cache decodes as code not tables (me) > and add new ones (based on updates by > Asit Mallick & Andrew Ip) > o Fix CMOS locking in machine_power_off paths (me) > o Create build tree symlinks only if insmod is > new enough not to be confused by it (Keith Owens) > o Fix cmsg handling (Philippe Troin) > o Tiny xpds driver changes(Dan Hollis) > o Fix vmalloc sign bug(Ben LaHaise) > o SMBFS fixes/changes for find_next problems and (Urban Widmark) > to avoid truncate bug in netapps > o Fix ntfs translation bug(Anton Altaparmakov) > o Fix sparc problem with some soundcards and the (Jeff Garzik) > _IOC magic
Re: Linux 2.2.18pre22
On Sun, Nov 19, 2000 at 12:57:35PM +, Alan Cox wrote: > > > o Small ISDN documentation fixes (Kai Germaschewski) > > > > Alan, On the ISDN issue, isdn4K-utils seems to be out of sync with=20 > > kernels older than 2.2.16. Some #define's that used to be in > > the 2.2.14 patch don't seem to be in 2.2.17 >. At present, requires > > an ugly .config patch to work under 2.2.18-21. =20 > > Shouldn't do. ISDN has changed between 2.2.16 and 2.2.18pre22 but not in any > way I am aware is bad. 2.2.19 has the merge of the rest of the isdn changes > queued. The Latest tar.gz in isdn4k-utils.src.rpm will not build. I went to ftp.isdn4linux.de and found the latest they have posted and the following errors are reported from the build. Against 2.4.0-10(11) isdn4k-utils-v3.1pre1.tar.gz ISDN_MODEM_ANZREG is undeclared in usr/src/linux/include/ Against 2.2.18-22same same problem 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/
Re: Linux 2.2.18pre22
On Sun, Nov 19, 2000 at 04:09:01PM +0100, Kai Germaschewski wrote:
> On Sun, 19 Nov 2000, Jeff V. Merkey wrote:
>
> > > o Small ISDN documentation fixes (Kai Germaschewski)
> >
> > Alan, On the ISDN issue, isdn4K-utils seems to be out of sync with
> > kernels older than 2.2.16. Some #define's that used to be in
> > the 2.2.14 patch don't seem to be in 2.2.17 >. At present, requires
> > an ugly .config patch to work under 2.2.18-21.
>
> It'ld be nice if you at least CC'ed your mail to the maintainers, i.e. the
> isdn4linux people, because not everyone has the time to follow l-k.
> Any way, I CC'ed [EMAIL PROTECTED] now, and this thread
> should continue there.
>
> Could you please clarify which problems you have? You state that the utils
> seem to be out of sync with kernels < 2.2.16, but you need to patch them
> for kernels > 2.2.17 ?
>
> I just tried the latest "release" of the utils,
> isdn4k-utils.v3.1pre1.tar.gz, and the current CVS version against
> 2.2.18pre22, and they compile fine. Note that binary compatibility didn't
> break during 2.2, only for 2.4. (I.e. utils compiled on 2.2 will complain
> if used with 2.4, utils compiled on 2.4 will work on either kernel series)
ISDN_MODEM_ANZREG undefined on 2.4.0-10(11) and 2.2.18-22, rpm.spec is
attached.
Jeff
Summary: Utilities for configuring an ISDN subsystem.
Name: isdn4k-utils
Version: 3.1
Release: 1
Copyright: GPL
Group: Applications/System
Source0:
ftp://ftp.isdn4linux.de/pub/isdn4linux/utils/testing/isdn4k-utils.v3.1beta7.tar.gz
Patch0: isdn4k-utils.patch
Patch1: isdn4k-utils-ipppd.patch
BuildRoot: /var/tmp/%name-root
Requires: initscripts >= 4.93
Prereq: /sbin/chkconfig
Vendor: Timpanogas Research Group, Inc.
Packager: [EMAIL PROTECTED]
%description
The isdn4k-utils package contains a collection of utilities needed for
configuring an ISDN subsystem.
%package -n xisdnload
Version: 1.38
Summary: An ISDN connection load average display for the X Window System.
Group: Applications/System
Requires: isdn4k-utils
%description -n xisdnload
The xisdnload utility displays a periodically updated histogram of the
load average over your ISDN connection.
%prep
%setup -q -n isdn4k-utils
%patch0
%patch1
cd capi20
libtoolize --copy --force
test -f /usr/include/capi20.h || cp capi20.h /usr/include/capi20.h
cd ..
%build
cp .config.rpm .config
make RPM_OPT_FLAGS="$RPM_OPT_FLAGS" subconfig
make RPM_OPT_FLAGS="$RPM_OPT_FLAGS"
%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/dev
mkdir -p $RPM_BUILD_ROOT/etc/rc.d/init.d
mkdir -p $RPM_BUILD_ROOT/etc/{ppp,isdn}
mkdir -p $RPM_BUILD_ROOT/var/{log/vbox,spool/vbox,lock/isdn}
mkdir -p $RPM_BUILD_ROOT/usr/{sbin,X11R6/bin}
chmod 1777 $RPM_BUILD_ROOT/var/spool/vbox
make install DESTDIR=$RPM_BUILD_ROOT
mv -fv $RPM_BUILD_ROOT/usr/bin/x* $RPM_BUILD_ROOT/usr/X11R6/bin/
mv -fv $RPM_BUILD_ROOT/usr/man/man1/x* $RPM_BUILD_ROOT/usr/X11R6/man/man1/
touch $RPM_BUILD_ROOT/etc/ppp/ioptions
test -f $RPM_BUILD_ROOT/etc/isdn/isdn.conf.new && \
mv -f $RPM_BUILD_ROOT/etc/isdn/isdn.conf.new $RPM_BUILD_ROOT/etc/isdn/isdn.conf
strip $RPM_BUILD_ROOT/usr/bin/* $RPM_BUILD_ROOT/usr/sbin/* \
$RPM_BUILD_ROOT/usr/X11R6/bin/* || :
# build some more documentation
pushd FAQ/tutorial ; {
sgml2txt EN-i4l.sgml
sgml2html EN-i4l.sgml
} ; popd
chmod 0755 $RPM_BUILD_ROOT/usr/bin/vboxbeep
%post
test -f /dev/isdnctrl || ln -sf isdnctrl0 /dev/isdnctrl
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root)
%dir /etc/isdn
%dir /var/spool/vbox
%dir /var/log/vbox
%verify(not md5 size mtime) %config(noreplace) /etc/isdn/*
/etc/ppp/ioptions
/usr/bin/*
/usr/include/*
/usr/lib/*.a
/usr/lib/*.so.*
/usr/man/man?/*
/usr/sbin/*
%doc COPYING HOWTO README
%lang(de) %doc vbox/doc/de/vbox.sgml vbox/doc/de/vbox.txt
%doc FAQ/tutorial/EN-i4l* FAQ/i4lfaq* Mini-FAQ/* FAQ/_howto/* FAQ/_example/*
#%lang(de) %doc FAQ/out/de-i4l-faq.asc FAQ/out/de-i4l-faq.html
%doc FAQ/_howto FAQ/_example FAQ/tutorial/*.txt FAQ/tutorial/*.html
%files -n xisdnload
%defattr(-,root,root)
/usr/X11R6/bin/xisdnload
%attr(0755,root,root) /usr/X11R6/bin/xmonisdn
/usr/X11R6/lib/X11/app-defaults/*
/usr/X11R6/man/man1/*
/usr/X11R6/include/X11/bitmaps/*
%doc xmonisdn/README
%changelog
Re: NCPFS not returning Volume Size (???)
On Sun, Nov 19, 2000 at 05:10:06PM +0100, Petr Vandrovec wrote:
> On Thu, Nov 16, 2000 at 08:40:29PM -0700, Jeff V. Merkey wrote:
> > Petr,
> >
> > NCPFS in 2.2.18-pre21 is not returning volume size via df -h. I checked
> > your code and found this comment:
> >
> > static int ncp_statfs(struct super_block *sb, struct statfs *buf, int bufsiz)
> > {
> > NCP Code
> >
> > /17E6 Get Object's Remaining Disk Space
> >
> > I noticed that 2.4 also is not reporting Volume free space.
>
> Yes, it is intentional. There are two different things:
> (1) you can mount all volumes from server to one mountpoint, and all these
> volumes share one superblock. So it is not clear, which value to
> return. Sum of all volume sizes?
> (2) in Netware, each directory can have its own space limit, so
> returned free space should differ from directory to directory.
> As statfs is per-superblock thing, I believe that returning
> 'sorry, I do not know' is better.
>
> > grouped into case/switch classes. If you can point me to
> > where 1) the login ID is stored and B) where NCP packet
> > request/reponse headers are constructed, i.e. a skeleton
> > to send/receive the requests I can grab, I'll try to
> > code this for you.
>
> loginID is not stored anywhere in kernel. You can look at
> ioctl(,NCP_IOC_GETOBJECTNAME,...). If you need your own ID
> so you know which disk space restriction retrieve, you'll have
> to first execute retrieve logged in info for current connection
> (where connection number is stored in server->connection).
>
> request/reply is built in preallocated space, you can look
> at functions in ncplib_kernel.c, f.e. ncp_open_create_file_or_subdir
> uses almost every of ncp_add_* functions. ncp_request() then
> executes RPC call and ncp_unlock_server() unlocks connection.
> You must NOT access userspace between ncp_init_request()
> and ncp_unlock_server() function, or deadlock can occur.
>
There's is a method to obtain this accurately. NSS may have
changed some things. I have a list of four issues now with this
one I need to get finished. I may need some help with your code
as I go.
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/
Re: Linux 2.2.18pre22
On Mon, Nov 20, 2000 at 11:10:21AM +0100, Kai Germaschewski wrote: > > On Sun, 19 Nov 2000, Jeff V. Merkey wrote: > > > ISDN_MODEM_ANZREG undefined on 2.4.0-10(11) and 2.2.18-22, rpm.spec is > > attached. > > This has been fixed 2000/03/03, see below. Just use the latest version, > ftp.isdn4linux.de/pub/isdn4linux/utils/isdn4k-utils.v3.1pre1.tar.gz > > --Kai This patch was not included in the pre1.tar.gz I downloaded last week. You may want to check the binary and make certain it's got the later file. I will check our archives as well. You will note the rpm.spec file I sent you was pulling the pre1.tar.gz off your site directly during the build, (RPM is a studly tool). Jeff > > > Index: iprofd.c > === > RCS file: /i4ldev/isdn4k-utils/iprofd/iprofd.c,v > retrieving revision 1.7 > retrieving revision 1.8 > diff -u -r1.7 -r1.8 > --- iprofd.c 1999/09/06 08:03:25 1.7 > +++ iprofd.c 2000/03/03 12:45:53 1.8 > @@ -1,4 +1,4 @@ > -/* $Id: iprofd.c,v 1.7 1999/09/06 08:03:25 fritz Exp $ > +/* $Id: iprofd.c,v 1.8 2000/03/03 12:45:53 calle Exp $ > > * Daemon for saving ttyIx-profiles to a file. > * > @@ -22,6 +22,9 @@ > * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. > * > * $Log: iprofd.c,v $ > + * Revision 1.8 2000/03/03 12:45:53 calle > + * Make compile with newer versions of kernel drivers. > + * > * Revision 1.7 1999/09/06 08:03:25 fritz > * Changed my mail-address. > * > @@ -67,8 +70,12 @@ > #ifndef ISDN_LMSNLEN > #define ISDN_LMSNLEN 0 > #endif > + > +#ifndef ISDN_MODEM_NUMREG > +#define ISDN_MODEM_NUMREG ISDN_MODEM_ANZREG > +#endif > > -#define BUFSZ ((ISDN_MODEM_ANZREG+ISDN_MSNLEN+ISDN_LMSNLEN)*ISDN_MAX_CHANNELS) > +#define BUFSZ ((ISDN_MODEM_NUMREG+ISDN_MSNLEN+ISDN_LMSNLEN)*ISDN_MAX_CHANNELS) > > void > dumpModem(int dummy) > > - 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: Defective Red Hat Distribution poorly represents Linux
On Mon, Nov 20, 2000 at 08:53:19AM -0500, Charles Turner, Ph.D. wrote:
Charles,
6.2 is one of te better distributions. You should also go talk to RedHat
directly.
Jeff
>
> I tried to help a friend this weekend convert to Linux.
> He lives in Upstate New York, so it was a long trip from
> Cambridge, Massachusetts.
>
> He has a Dual Pentium III, 600 MHz TYAN "Thunderbolt".
> It has a built-in Adaptec SCSI controller and Intel
> 100-base-T Ethernet controller. It also has 1/2 Gbytes
> of RAM. It's a superb machine.
>
> It had been running Windows 2000 "Professional". Several months
> ago, he purchased Red Hat "DELUXE" version 6.2. He was unable to
> install it. I convinced him that installation was easy.
>
> I was terribly wrong. This Red Hat version is irrevocably defective.
>
> (1) It will not create a bootable disk because it forgets
> to load scsi_mod.o, and sd_mod.o before it loads
> aic7xxx.o
> /etc/conf.modules was found to contain only aic7xxx
> as an alias for scsi_hostadapter.
>
> (2) Once I made a bootable diskette from a working machine
> at home (200 miles round-trip distance), I was able to
> install its supplied kernel version 2.2.14-5.0, and
> 2.2.14-5.0smp into the LILO boot sequence.
>
> (3) It "sort of" worked. However, network daemons kept
> dropping core. X would eventually crash, leaving the
> terminal in an unusable state, etc.
>
> (4) It is impossible to build a known working kernel on the
> machine because the linker, `ld` crashes:
>
> Script started on Sun Nov 19 19:11:55 2000
> [root@merrimac linux-2.2.17]# make dep
> gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/mkdep
>scripts/mkdep.c
> collect2: ld terminated with signal 11 [Segmentation fault], core dumped
> make: *** [scripts/mkdep] Error 1
> [root@merrimac linux-2.2.17]# ld --version
> GNU ld 2.9.5
> Copyright 1997 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License. This program has absolutely no warranty.
> Supported emulations:
>elf_i386
>i386linux
> [root@merrimac linux-2.2.17]# cd scripts
> [root@merrimac scripts]# gcc -o mkdep.o mkdep.c
> collect2: ld terminated with signal 11 [Segmentation fault], core dumped
> [root@merrimac scripts]# gcc -c -o mkdep.o mkdep.c
> [root@merrimac scripts]# ld -o mkdep mkdep.o
> Segmentation fault (core dumped)
>
> [root@merrimac scripts]# strace ld -o mkdep mkdep.c
> execve("/usr/bin/ld", ["ld", "-o", "mkdep", "mkdep.o"], [/* 20 vars */]) = 0
> brk(0) = 0x807bb84
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
>0x40014000
> open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
> open("/etc/ld.so.cache", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=16290, ...}) = 0
> old_mmap(NULL, 16290, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40015000
> close(3)= 0
> open("/usr/lib/libbfd-2.9.5.0.22.so", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=314936, ...}) = 0
> read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\242"..., 4096) = 4096
> old_mmap(NULL, 279260, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40019000
> mprotect(0x40059000, 17116, PROT_NONE) = 0
> old_mmap(0x40059000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x3f000)
>= 0x40059000
> old_mmap(0x4005d000, 732, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,
>-1, 0) = 0x4005d000
> close(3)= 0
> open("/lib/libdl.so.2", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=75131, ...}) = 0
> read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\34"..., 4096) = 4096
> old_mmap(NULL, 12428, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4005e000
> mprotect(0x4006, 4236, PROT_NONE) = 0
> old_mmap(0x4006, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1000) =
>0x4006
> close(3)= 0
> open("/lib/libc.so.6", O_RDONLY)= 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=4101324, ...}) = 0
> read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\210\212"..., 4096) = 4096
> old_mmap(NULL, 1001564, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40062000
> mprotect(0x4014f000, 30812, PROT_NONE) = 0
> old_mmap(0x4014f000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xec000)
>= 0x4014f000
> old_mmap(0x40153000, 14428, PROT_READ|PROT_WRITE,
>MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40153000
> close(3)= 0
> mprotect(0x40062000, 970752, PROT_READ|PROT_WRITE) = 0
> mprotect(0x40062000, 970752, PROT_READ|PROT_EXEC) = 0
> munmap(0x40015000, 16290) = 0
> personality(PER_LINUX) = 0
> getpid()= 763
> getrusage(RUSAGE_SELF, {ru_utime={0, 0}, ru_stime={0, 0}, ...}) = 0
>
Re: Linux 2.2.18pre22 (ISDN4K errors)
We were using the attached spec file for 3.1pre1 and the other file for
3.1beta7 (sorry I posted the wrong file, it was about 2 a.m. in the
morning). When built against 2.2.18-21 with 3.1pre1, I get a whole new
slew of errors. Neither seems to work. I have attached the 3.1pre1
spec file which points to the newer version. I removed the config and
kernel patches from the build since the last patch is for 2.2.14 and
fails to apply to 2.1.8-21. Here are the results.
against 2.2.18-pre21 and 2.4.0-10(11)
CAPI_GET_FLAGS undeclared
CAPI_SET_FLAGS undeclared
CAPI_CLR_FLAGS undeclared
CAPI_NCCI_GETUNIT undeclared
CAPI_NCCI_OPENCOUT undeclared.
Jeff
Summary: Bundled Utilities for configuring an using ISDN4Linux
Name: isdn4k-utils
Version: v3.1pre1
Release: 1
Copyright: GPL
Group: Base
Source0: ftp://ftp.franken.de/pub/isdn4linux/v2.0/isdn4k-utils-v3.1pre1.tar.gz
URL: http://www.isdn4linux.de
#Distribution: Unknown
Vendor: The ISDN4Linux Team
Packager: Fritz Elfert <[EMAIL PROTECTED]>
Requires: kernel >= 2.0.36
BuildRoot: /var/tmp/isdn4k-utils-root
%description
isdn4k-utils is a collection of various ISDN related utilities. This
package contains configuration tools for all ISDN adapters, supported
by Linux. Furthermore, several status-monitors are provided as well as
some ISDN-based applications. Namely ipppd, a PPP daemon for synchronous
PPP over ISDN; vbox, an answering-machine and (for use with AVM-B1 only)
capifax, a faxmachine.
%prep
# remove old directory
if [ "X" != "${RPM_BUILD_ROOT}X" ]; then
rm -rf $RPM_BUILD_ROOT
fi
rm -rf $RPM_BUILD_DIR/isdn4k-utils-%{PACKAGE_VERSION}
mkdir $RPM_BUILD_DIR/isdn4k-utils-%{PACKAGE_VERSION}
# unpack main sources
%setup -n isdn4k-utils-%{PACKAGE_VERSION}
%build
cp .config.rpm .config
make RPM_OPT_FLAGS="$RPM_OPT_FLAGS" subconfig
make RPM_OPT_FLAGS="$RPM_OPT_FLAGS"
%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/usr/{sbin,bin,man,include}
mkdir -p $RPM_BUILD_ROOT/usr/lib/isdn
mkdir -p $RPM_BUILD_ROOT/etc/isdn
mkdir -p $RPM_BUILD_ROOT/dev
make DESTDIR=$RPM_BUILD_ROOT install
cd $RPM_BUILD_ROOT/etc/isdn
for i in *.new ; do
mv $i `basename $i .new`
done
%clean
if [ "X" != "${RPM_BUILD_ROOT}X" ]; then
rm -rf $RPM_BUILD_ROOT
fi
%files
/dev
/sbin
/usr/bin
/usr/lib/isdn
/usr/lib/libcapi20.a
/usr/include
/usr/X11R6/include/X11/bitmaps
%config /usr/X11R6/lib/X11/app-defaults/*
%dir /etc/isdn
%config /etc/isdn/vboxgetty.conf
%config /etc/isdn/vboxd.conf
%config /etc/isdn/isdn.conf
%doc /usr/man/man1/*
%doc /usr/man/man4/*
%doc /usr/man/man5/*
%doc /usr/man/man7/*
%doc /usr/man/man8/*
%doc /usr/doc/vbox/*
%doc /usr/X11R6/man/man1/*
%doc /usr/doc/faq/isdn4linux/*
%dir /var/spool/vbox
%dir /var/log/vbox
[Fwd: Linux 2.2.18pre22 (ISDN4K errors)]
My NT box fritzed on sending this via outlook express, so I lost Kai's
email (MUTT works better on Linux). Here's the other info he inquired
about on the 3.1pre1 compile problems.
Jeff
We were using the attached spec file for 3.1pre1 and the other file for
3.1beta7 (sorry I posted the wrong file, it was about 2 a.m. in the
morning). When built against 2.2.18-21 with 3.1pre1, I get a whole new
slew of errors. Neither seems to work. I have attached the 3.1pre1
spec file which points to the newer version. I removed the config and
kernel patches from the build since the last patch is for 2.2.14 and
fails to apply to 2.1.8-21. Here are the results.
against 2.2.18-pre21 and 2.4.0-10(11)
CAPI_GET_FLAGS undeclared
CAPI_SET_FLAGS undeclared
CAPI_CLR_FLAGS undeclared
CAPI_NCCI_GETUNIT undeclared
CAPI_NCCI_OPENCOUT undeclared.
Jeff
Summary: Bundled Utilities for configuring an using ISDN4Linux
Name: isdn4k-utils
Version: v3.1pre1
Release: 1
Copyright: GPL
Group: Base
Source0: ftp://ftp.franken.de/pub/isdn4linux/v2.0/isdn4k-utils-v3.1pre1.tar.gz
URL: http://www.isdn4linux.de
#Distribution: Unknown
Vendor: The ISDN4Linux Team
Packager: Fritz Elfert <[EMAIL PROTECTED]>
Requires: kernel >= 2.0.36
BuildRoot: /var/tmp/isdn4k-utils-root
%description
isdn4k-utils is a collection of various ISDN related utilities. This
package contains configuration tools for all ISDN adapters, supported
by Linux. Furthermore, several status-monitors are provided as well as
some ISDN-based applications. Namely ipppd, a PPP daemon for synchronous
PPP over ISDN; vbox, an answering-machine and (for use with AVM-B1 only)
capifax, a faxmachine.
%prep
# remove old directory
if [ "X" != "${RPM_BUILD_ROOT}X" ]; then
rm -rf $RPM_BUILD_ROOT
fi
rm -rf $RPM_BUILD_DIR/isdn4k-utils-%{PACKAGE_VERSION}
mkdir $RPM_BUILD_DIR/isdn4k-utils-%{PACKAGE_VERSION}
# unpack main sources
%setup -n isdn4k-utils-%{PACKAGE_VERSION}
%build
cp .config.rpm .config
make RPM_OPT_FLAGS="$RPM_OPT_FLAGS" subconfig
make RPM_OPT_FLAGS="$RPM_OPT_FLAGS"
%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/usr/{sbin,bin,man,include}
mkdir -p $RPM_BUILD_ROOT/usr/lib/isdn
mkdir -p $RPM_BUILD_ROOT/etc/isdn
mkdir -p $RPM_BUILD_ROOT/dev
make DESTDIR=$RPM_BUILD_ROOT install
cd $RPM_BUILD_ROOT/etc/isdn
for i in *.new ; do
mv $i `basename $i .new`
done
%clean
if [ "X" != "${RPM_BUILD_ROOT}X" ]; then
rm -rf $RPM_BUILD_ROOT
fi
%files
/dev
/sbin
/usr/bin
/usr/lib/isdn
/usr/lib/libcapi20.a
/usr/include
/usr/X11R6/include/X11/bitmaps
%config /usr/X11R6/lib/X11/app-defaults/*
%dir /etc/isdn
%config /etc/isdn/vboxgetty.conf
%config /etc/isdn/vboxd.conf
%config /etc/isdn/isdn.conf
%doc /usr/man/man1/*
%doc /usr/man/man4/*
%doc /usr/man/man5/*
%doc /usr/man/man7/*
%doc /usr/man/man8/*
%doc /usr/doc/vbox/*
%doc /usr/X11R6/man/man1/*
%doc /usr/doc/faq/isdn4linux/*
%dir /var/spool/vbox
%dir /var/log/vbox
NFS 2.4.0-11 noisy messages/NFS rpc.lockd returns error
doing a mount :/dir /mount_point generates the following noisy error messages: kmem_create: Forcing size word alignment - nfs-fh also, the rpc.lockd program is reporting an error when invoked from the System V init startup scripts: lockd: lockdsvc: invalid argument during system initialization with init 2.78. The radio-miropcm20.o driver reports 3 unresolved externals (apm_ functions) and fails with depmod errors during init. 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/
Re: NFS 2.4.0-11 noisy messages/NFS rpc.lockd returns error
Ion Badulescu wrote: > > On Mon, 20 Nov 2000 17:56:20 -0700, Jeff V. Merkey <[EMAIL PROTECTED]> wrote: > > > also, the rpc.lockd program is reporting an error when invoked from the > > System V init startup scripts: > > > > lockd: lockdsvc: invalid argument > > lockd is a kernel thread nowadays, remove it from your nfsd start script > or simply ignore the error (if you want compatibility with 2.2 kernels > before 2.2.18). > Thanks. I saw [lockd] running from ps -ax along with [rpciod] -- performance was also significantly faster. 2.2 compatibility is a problem, but not a serious one. I am updating initscripts.rpm. More stuff in the kernel is always better. Jeff > Ion > > -- > It is better to keep your mouth shut and be thought a fool, > than to open it and remove all doubt. - 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 2.2.18-22 with non-existent TCPIP route
Alan, I have an Oops with 2.2.18-22 that only shows up on a Linux server that's configured as a pppd dial in server with dynamic address assignment (no DHCP). Host IP addresses are configured in an options.ttyS0(192.168.0.1) and options.ttyS1(192.168.0.2) files in /etc/ppp. We caused the Oops by accident when we misconfigured our Cisco CPA 2501 router with a static route for network 207.225.212.40 (mask 255.255.255.248) that pointed to this server (the server had no routes to this network but used to). We were moving some servers around to segregate the law firm onto a private network. I was not running ksymoops but have it setup now and we are attempting to recreate the conditions that produced the oops. The Oops reported is crashed in process slocate (clearly misleading -- looks like an Oops from an interrupt). We will attempt to get the Oops again. 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/
Re: e2fs performance as function of block size
Alan Cox wrote: > > > Sirs, > > performing extensive tests on linux platform performance, optimized as > > database server, I got IMHO confusing results: > > in particular e2fs initialized to use 1024 block/fragment size showed > > significant I/O gains over 4096 block/fragment size, while I expected t= > > he > > opposite. I would appreciate some hints to understand this. > > It may be that your database is writing out 1K sized blocks on random > boundaries. If so then the behaviour you describe would be quite reasonable. Alan, Perhaps, but I have reported this before and seen something similiar. It's as though the disk drivers are optimized for this case (1024). I get better performance running NWFS at 1024 block size vs. all the other sizes, even with EXT2 configured to use 4096, etc. At first glance, when I was changing block sizes, I did note that by default, EXT2 set to 1024 would mix buffer sizes in the buffer cache, which skewed caching behavior, but there is clearly some optimization relative to this size inherent in the design of Linux -- and it may be a pure accident. This person may be mixing and matching block sizes in the buffer cache, which would satisfy your explanation. 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: e2fs performance as function of block size
Alan Cox wrote: > > > It's as though the disk drivers are optimized for this case (1024). I > > The disk drivers are not, and they normally see merged runs of blocks so they > will see big chunks rather than 1K then 1K then 1K etc. > > > behavior, but there is clearly some optimization relative to this size > > inherent in the design of Linux -- and it may be a pure accident. This > > person may be mixing and matching block sizes in the buffer cache, which > > would satisfy your explanation. > > I see higher performance with 4K block sizes. I should see higher latency too ^ Since buffer heads are chained, this would make sense. > but have never been able to measure it. Maybe it depends on the file system. > It certainly depends on the nature of requests Could be. NWFS likes 4K block sizes -- this is it's default. On linux, I've been emulating other block sizes beneath it. I see best performance at 1024 byte blocks, worst at 512. The overhead of buffer chaining is clearly the culprit. On the TCPIP oops on 2.2.18-22, I have not been able to reproduce it reliably. It appears to be in the ppp code, however, and not the TCPIP code. The problem only shows up after several pppd connections have accessed the box then terminated the connections (which is why I think it's pp related). I would rate this as a level IV bug due to the difficulty in creating it, and the fact that you have to deliberately misconfigure a TCPIP network to make it show up. Jeff 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/
modutils 2.3.20 not backward compatible
Keith, Was there a reason we removed the -i and -m options from newer modutils and broke backwards caompatibility? I'm re-writing our module build scripts for the installer, and I discovered after upgrading to 2.3.20, that all the build scripts (about 10MB worth) are now busted and I have been spending most of this evening rewriting them so they work again. Thanks 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/
Re: modutils 2.3.20 not backward compatible
Keith Owens wrote: > > On Tue, 21 Nov 2000 20:17:47 -0700, > "Jeff V. Merkey" <[EMAIL PROTECTED]> wrote: > >Was there a reason we removed the -i and -m options from newer modutils > >and broke backwards caompatibility? I'm re-writing our module build > >scripts for the installer, and I discovered after upgrading to 2.3.20, > >that all the build scripts (about 10MB worth) are now busted and I have > >been spending most of this evening rewriting them so they work again. > > -i and -m have never been in the base code. -i in depmod is a Redhat > add on, only in their distribution. I have no idea what -m does, apart > from -m in insmod which is supported. Blame the distributors. Thanks for clarifying. -i ignores certain dependency failures, and is very dangerous. -m lets you use a map file. If what you say is correct, then it was an erstwhile exercise rewriting these scripts, since they will now take generic parameters. 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: [patch] O_SYNC patch 3/3, add inode dirty buffer list support to ext2
On Wed, Nov 22, 2000 at 11:26:46AM +, Stephen C. Tweedie wrote:
> Hi,
>
> This final part of the O_SYNC patches adds calls to ext2, and to
> generic_commit_write, to record dirty buffers against the owning
> inode. It also removes most of fs/ext2/fsync.c, which now simply
> calls the generic sync code.
>
> --Stephen
Stephen,
I have not implemented O_SYNC in NWFS, but it looks like I need to add it
before posting the final patches. This patch appears to force write-through
of only dirty inodes, and allow reads to continue from cache. Is this
assumption correct, and does this comply with TPC rules for ORACLE and
other DBMS benchmarks? It looks like a good patch that will perform
very fast for O_SYNC.
Jeff
>
> 2.4.0test11.02.ext2-osync.diff :
>
>
> --- linux-2.4.0-test11/fs/buffer.c.~1~Tue Nov 21 15:51:17 2000
> +++ linux-2.4.0-test11/fs/buffer.cTue Nov 21 16:35:35 2000
> @@ -1727,6 +1727,7 @@
> set_bit(BH_Uptodate, &bh->b_state);
> if (!atomic_set_buffer_dirty(bh)) {
> __mark_dirty(bh);
> + buffer_insert_inode_queue(bh, inode);
> need_balance_dirty = 1;
> }
> }
> --- linux-2.4.0-test11/fs/ext2/fsync.c.~1~Tue Nov 21 15:47:48 2000
> +++ linux-2.4.0-test11/fs/ext2/fsync.cTue Nov 21 16:01:15 2000
> @@ -28,98 +28,6 @@
> #include
>
>
> -#define blocksize(EXT2_BLOCK_SIZE(inode->i_sb))
> -#define addr_per_block (EXT2_ADDR_PER_BLOCK(inode->i_sb))
> -
> -static int sync_indirect(struct inode * inode, u32 * block, int wait)
> -{
> - struct buffer_head * bh;
> -
> - if (!*block)
> - return 0;
> - bh = get_hash_table(inode->i_dev, le32_to_cpu(*block), blocksize);
> - if (!bh)
> - return 0;
> - if (wait && buffer_req(bh) && !buffer_uptodate(bh)) {
> - /* There can be a parallell read(2) that started read-I/O
> -on the buffer so we can't assume that there's been
> -an I/O error without first waiting I/O completation. */
> - wait_on_buffer(bh);
> - if (!buffer_uptodate(bh))
> - {
> - brelse (bh);
> - return -1;
> - }
> - }
> - if (wait || !buffer_uptodate(bh) || !buffer_dirty(bh)) {
> - if (wait)
> - /* when we return from fsync all the blocks
> -must be _just_ stored on disk */
> - wait_on_buffer(bh);
> - brelse(bh);
> - return 0;
> - }
> - ll_rw_block(WRITE, 1, &bh);
> - atomic_dec(&bh->b_count);
> - return 0;
> -}
> -
> -static int sync_iblock(struct inode * inode, u32 * iblock,
> - struct buffer_head ** bh, int wait)
> -{
> - int rc, tmp;
> -
> - *bh = NULL;
> - tmp = le32_to_cpu(*iblock);
> - if (!tmp)
> - return 0;
> - rc = sync_indirect(inode, iblock, wait);
> - if (rc)
> - return rc;
> - *bh = bread(inode->i_dev, tmp, blocksize);
> - if (!*bh)
> - return -1;
> - return 0;
> -}
> -
> -static int sync_dindirect(struct inode * inode, u32 * diblock, int wait)
> -{
> - int i;
> - struct buffer_head * dind_bh;
> - int rc, err = 0;
> -
> - rc = sync_iblock(inode, diblock, &dind_bh, wait);
> - if (rc || !dind_bh)
> - return rc;
> -
> - for (i = 0; i < addr_per_block; i++) {
> - rc = sync_indirect(inode, ((u32 *) dind_bh->b_data) + i, wait);
> - if (rc)
> - err = rc;
> - }
> - brelse(dind_bh);
> - return err;
> -}
> -
> -static int sync_tindirect(struct inode * inode, u32 * tiblock, int wait)
> -{
> - int i;
> - struct buffer_head * tind_bh;
> - int rc, err = 0;
> -
> - rc = sync_iblock(inode, tiblock, &tind_bh, wait);
> - if (rc || !tind_bh)
> - return rc;
> -
> - for (i = 0; i < addr_per_block; i++) {
> - rc = sync_dindirect(inode, ((u32 *) tind_bh->b_data) + i, wait);
> - if (rc)
> - err = rc;
> - }
> - brelse(tind_bh);
> - return err;
> -}
> -
> /*
> * File may be NULL when we are called. Perhaps we shouldn't
> * even pass file to fsync ?
> @@ -127,34 +35,20 @@
>
> int ext2_sync_file(struct file * file, struct dentry *dentry, int datasync)
> {
> - int wait, err = 0;
> struct inode *inode = dentry->d_inode;
> + return ext2_fsync_inode(inode, datasync);
> +}
>
> - lock_kernel();
> - if (S_ISLNK(inode->i_mode) && !(inode->i_blocks))
> - /*
> - * Don't sync fast links!
> - */
> - goto skip;
> -
> - err = generic_buffer_fdatasync(inode, 0, ~0UL);
> -
> - for (wait=0; wait<=1; wait++)
> - {
> - err |= sy
Re: Announce: modutils 2.3.21 is available
On Wed, Nov 22, 2000 at 11:25:17PM +1100, Keith Owens wrote: > This is the "never release a security fix in a hurry" release. The > security fixes in modutils 2.3.20 had some side effects on some config > files. Linus knocked back environment variable MOD_SAFEMODE, instead > the kernel propagates the real uid that caused modprobe to be invoked. > > ftp://ftp..kernel.org/pub/linux/utils/kernel/modutils/v2.3 > > patch-modutils-2.3.21.bz2 Patch from modutils 2.3.20 to 2.3.21 > modutils-2.3.21.tar.bz2 Source tarball, includes RPM spec file > modutils-2.3.21-1.src.rpm As above, in SRPM format > modutils-2.3.21-1.i386.rpm Compiled with egcs-2.91.66, glibc 2.1.2 > modutils-2.3.21-1.sparc.rpm Compiled for combined sparc 32/64 > > Changelog extract > > * Remove compile warnings in xstrcat. > * snprintf cleanups. > * Set safemode when uid != euid. > * Strip quotes from shell responses. + add RedHat ism's with a --rhc (red hat compatible) -i -m (-F) RedHat kind of is the standard in the commercial world in the US. :-) 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/
AGP patches for 2.2.X kernels
Alan, I noticed that the AGP patches are present in RH6.2 and 7.0, and that the agp support is integrated in 2.4.0. Do you know where the patches are for the 2.2.18 kernels for AGP. Thanks 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/
Re: Announce: modutils 2.3.21 is available
On Wed, Nov 22, 2000 at 10:19:17AM -0800, Andre Hedrick wrote: > On Wed, 22 Nov 2000, Jeff V. Merkey wrote: > > > + add RedHat ism's with a --rhc (red hat compatible) -i -m (-F) > > > > RedHat kind of is the standard in the commercial world in the US. > > Regardless of the bogus nature of this statement, boss. > GNU/OS packages are to be modified locally and a generic form that does > not have flavor or spin is what maintainers release. > > Regards, The -m option is a good idea. Strange since most of the commercial releases implement these additions. I just hope Keith has a good sense of humor. :-) Jeff > > Andre Hedrick > CTO Timpanogas Research Group > EVP Linux Development, TRG > Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
iBCS2 and 2.4.0-11 Can we make soup yet?
I noticed that iBC2 support no longer builds against 2.4.0-11. I also found that 11/98 seems to be the last version of iBCS2 posted. 2.4.0-11 does have a MISC binary loadable option, but I did not see iBCS2 in the tree. Is there something more recent, or is iBCS2 something that's basically no longer considered critical for Linux? Thanks 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/
Oops on 2.2.18-23 as pppd dial in server
Alan, Was able to reproduce this Oops, but it took several days. Oops occurs against 2.2.18-23. I had to copy this info from the console -- the system was hard hung after the oops and even ksymoops was locked solid. Jeff unable to handle kernel paing request virtual address 90C16C24 CR3-0187 pde=0 Oops: 0002 CPU: 0 EIP 0010: C0137596 EFLAGS: 00010206 eax: 90c16c20 ebx: c16c6145 ecx: edx: c0226e2c esi: c0259200 edi: c16c614d ebp: c0259200 esp: c17f9ee8 ds: 18 es: 18 ss: 18 process solcate pid: 1109 nr: 45 stack=c17f9000 Call Trace: c01377fe c0137816 c0144bbc c0131238 c0131434 c013151c c012f532 c010a2fc - 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 on 2.2.18-23 as pppd dial in server
I always type too fast. Yes, it's "slocate". Jeff "Mohammad A. Haque" wrote: > > solcate? .. you sure you don't mean slocate? > > "Jeff V. Merkey" wrote: > > process solcate pid: 1109 nr: 45 stack=c17f9000 > > -- > > = > Mohammad A. Haque http://www.haque.net/ >[EMAIL PROTECTED] > > "Alcohol and calculus don't mix. Project Lead >Don't drink and derive." --Unknown http://wm.themes.org/ >[EMAIL PROTECTED] > = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
setting up pppd dial-in on linux
Anyone out there a whiz at setting up a pppd dialin server? I am trying to put together an RPM for pppd dialin configurations that will support default Windows NT and Linux dial in clients without requiring the poor user to learn bash scripting, chat scripting, mgetty and inittab configuration, etc. The steps in setting this up are about as easy as going on a U.N. relief mission to equatorial Africa, and most customers who are "mere mortals" would give up about an hour into it. I am seeing massive problems with pppd dial-in and IP/IPX routing with problems that range from constant Oops, to the bug infested pppd daemon failing valid MD5 chap authentication. The HOW-TO's and man pages provide wonderful commentary on all the things about pppd that don't work, but it's not too helpful on getting it to work reliably. An NT dial-in server takes about 5 minutes to configure on W2K. Linux takes about 2 days, and won't stay up reliably. Who out there is an expert on Linux pppd that would like to help put together some easy configs for standard dial-in scenarios? Thanks 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/
Re: setting up pppd dial-in on linux
On Fri, Nov 24, 2000 at 11:48:06PM -0800, J Sloan wrote: > "Jeff V. Merkey" wrote: > > > Anyone out there a whiz at setting up a pppd dialin server? I am > > trying to put together an RPM for pppd dialin configurations > > that will support default Windows NT and Linux dial in clients > > without requiring the poor user to learn bash scripting, chat > > scripting, mgetty and inittab configuration, etc. The steps > > in setting this up are about as easy as going on a U.N. relief > > mission to equatorial Africa, and most customers who are > > "mere mortals" would give up about an hour into it. > > Red Hat's ppp client setup is about a 90 second job I am using theirs as a base. Setup's not the issue. It's the chap MD5 authentication for NT clients and the constant crashing that's troublesome. I have it working, just not with NT clients. > > > I am seeing massive problems with pppd dial-in and IP/IPX > > routing with problems that range from constant Oops, to > > the bug infested pppd daemon failing valid MD5 chap > > authentication. The HOW-TO's and man pages provide > > wonderful commentary on all the things about pppd > > that don't work, but it's not too helpful on getting > > it to work reliably. An NT dial-in server takes about > > 5 minutes to configure on W2K. Linux takes about 2 days, and > > won't stay up reliably. > > hmm, an awful lot of ISPs use Linux dialup servers... > > I set up a linux ppp server back in 1996 - things might have > changed, but it seemed fairly straightforward at the time - > > can't imagine it's gotten worse since then... > > > Who out there is an expert on Linux pppd that would like > > to help put together some easy configs for standard > > dial-in scenarios? > > Crunch time for me right now, finals coming right up... Thank's anyway. I'll keep working on the bugs. :-) Jeff > > I'll bet there's quite a few ISP-savvy admins who could > lend a hand though - > > jjs > - 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: setting up pppd dial-in on linux
On Sat, Nov 25, 2000 at 02:28:56PM +0100, Pedro M. Rodrigues wrote: > >You are not alone. And the problem gets even worse when you > have to deal with ISDN devices. In my company´s data room we > have all Linux servers running 365 days a year (minus upgrade > time) and in one corner a lonely Windows NT Server 3.0 with 5 > Client Access Licenses working as a RAS server for 2 Diva Server > BRI cards (4 analog/digital channels) plus one analog modem. > Time to set it up? Half an hour counting NT installation. Time i lost > investigating and trying different configurations, dealing with > contradictory documentation, chat scripts, different ipppd versions, > and authentication failures? 2 days. At Ieast i cant complain about > pppd oops, as you do, the pppd in RH6.2 seemed solid. The > document of reference that seemed more interesting to me at the > time was http://www.swcp.com/~jgentry/pers.html , have a look > please. Thanks. We need to get the Linux stuff to the same point. From our analysis, it's the only weak feature left -- Linux either matches or surpasses NT in every other area now except this one. Jeff > > > Regards, > Pedro > > On 25 Nov 2000, at 0:36, Jeff V. Merkey wrote: > > > > > > > Anyone out there a whiz at setting up a pppd dialin server? I am > > trying to put together an RPM for pppd dialin configurations > > that will support default Windows NT and Linux dial in clients > > without requiring the poor user to learn bash scripting, chat > > scripting, mgetty and inittab configuration, etc. The steps > > in setting this up are about as easy as going on a U.N. relief > > mission to equatorial Africa, and most customers who are > > "mere mortals" would give up about an hour into it. > > > > I am seeing massive problems with pppd dial-in and IP/IPX > > routing with problems that range from constant Oops, to > > the bug infested pppd daemon failing valid MD5 chap > > authentication. The HOW-TO's and man pages provide > > wonderful commentary on all the things about pppd > > that don't work, but it's not too helpful on getting > > it to work reliably. An NT dial-in server takes about > > 5 minutes to configure on W2K. Linux takes about 2 days, and > > won't stay up reliably. > > > > Who out there is an expert on Linux pppd that would like > > to help put together some easy configs for standard > > dial-in scenarios? > > > > Thanks > > > > 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: setting up pppd dial-in on linux
On Sat, Nov 25, 2000 at 11:04:48AM -0600, William Scott Lockwood III wrote: > Jeff, > I am also VERY interested in this, particularly on getting modems to work > with Linux at all. I'm not reading the list right now, but I'd appreciate > any feedback you can throw my way on this. Esp. if you DO get it setup and > working. It sure would be nice to see Linux FINALLY support more modems out > there. Hell, my Internal USR ISA modem is not even supported, but FreeBSD > had had support for it for a long time now. :-( Please let me know what > you find out, and I'm VERY interested in your RPM - hope there will be a > straight tarball for us Slackware Dinosaurs too. :-) I'll post ot at vger.timpanogas.org with the Ute-NWFS distribution. It will be freely downloadable. Having plug and play NT dial-in support would be very nice. SuSe has a pretty nice setup, but we have as many, if not more problems with their's vs. RedHat and ours. Jeff > > Scott > > - Original Message - > From: "Jeff V. Merkey" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, November 25, 2000 1:36 AM > Subject: setting up pppd dial-in on linux > > > > > > > > Anyone out there a whiz at setting up a pppd dialin server? I am > > trying to put together an RPM for pppd dialin configurations > > that will support default Windows NT and Linux dial in clients > > without requiring the poor user to learn bash scripting, chat > > scripting, mgetty and inittab configuration, etc. The steps > > in setting this up are about as easy as going on a U.N. relief > > mission to equatorial Africa, and most customers who are > > "mere mortals" would give up about an hour into it. > > > > I am seeing massive problems with pppd dial-in and IP/IPX > > routing with problems that range from constant Oops, to > > the bug infested pppd daemon failing valid MD5 chap > > authentication. The HOW-TO's and man pages provide > > wonderful commentary on all the things about pppd > > that don't work, but it's not too helpful on getting > > it to work reliably. An NT dial-in server takes about > > 5 minutes to configure on W2K. Linux takes about 2 days, and > > won't stay up reliably. > > > > Who out there is an expert on Linux pppd that would like > > to help put together some easy configs for standard > > dial-in scenarios? > > > > Thanks > > > > 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: Oops on 2.2.18-23 as pppd dial in server
On Sat, Nov 25, 2000 at 06:22:57PM +0100, Chmouel Boudjnah wrote: > "Jeff V. Merkey" <[EMAIL PROTECTED]> writes: > > > Was able to reproduce this Oops, but it took several days. Oops occurs > > against 2.2.18-23. I had to copy this info from the console -- the > > system was hard hung after the oops and even ksymoops was locked solid. > > what type of mounted filesystem you have (dos/ext2) ? ext2/nwfs. I made the mitake of rebuilding the kernel so I have to recompile again to get the System.map file to ksymoops the crash. I will try to have it completed today and posted. Jeff > > -- > MandrakeSoft Inc http://www.chmouel.org > --Chmouel - 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: gcc-2.95.2-51 is buggy
On Sat, Nov 25, 2000 at 03:26:15PM -0200, Rik van Riel wrote: Rik, We refuse to use it here at present. Builds from it have a lot of problems, for some reason. Andre is looking into it more deeply than I, but I agree with your assessment. Jeff > On Fri, 24 Nov 2000, Neil Brown wrote: > > On Friday November 24, [EMAIL PROTECTED] wrote: > > > >> ... RedHat's GCC snapshot "2.96" handles this case just fine. > > > > > > > Now, if you can isolate the relevant part of the diff between > > > > 2.95.2 and RH 2.96... > > > > > > Maybe I have to be more precise in the statement "gcc 2.95.2 is buggy". > > [image from FTP site not buggy] > > > > This is from a SuSE distribution, I forget which, not very recent. > > > Revised summary: gcc-2.95.2-51 from SuSE is buggy. > > > > Ditto for gcc-2.95.2-13 from Debian (potato). It exhibits the > > same bug. Debian applies a total of 49 patches to gcc and the > > libraries. > > The gcc-2.95.2-6cl from Conectiva 6.0 is buggy too. > > (and the ISO images haven't even been available for > one week yet ... *sigh*) > > regards, > > Rik > -- > Hollywood goes for world dumbination, > Trailer at 11. > > 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/ - 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/
PCMCIA 3.1.22 needs patch for kernels > 2.2.18-23
David Hinds/Linux,
PCMCIA 3.1.22 requires that the defines in /include/pcmcia/k_compat.h
for init_waitqueue_head(n) and set_current_state(n) be removed in order
to build correctly against 2.2.18-23.
Offending code attached. This probably needs somethig better than the
LINUX_KERNEL_VERSION macro to avoid this problem in the future.
:-)
Jeff
in /include/pcmcia/k_compat.h
/*
#if (LINUX_VERSION_CODE < VERSION(2,2,18))
#if (LINUX_VERSION_CODE < VERSION(2,0,16))
#define init_waitqueue_head(p) (*(p) = NULL)
#else
#define init_waitqueue_head(p) init_waitqueue(p)
#endif
typedef struct wait_queue *wait_queue_head_t;
#endif
***/
and
#if (LINUX_VERSION_CODE < VERSION(2,1,0))
#define __set_current_state(n) \
do { current->state = TASK_INTERRUPTIBLE; } while (0)
#elif (LINUX_VERSION_CODE < VERSION(2,2,18))
//#define __set_current_state(n) do { current->state = (n); } while (0)
#endif
-
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] modutils 2.3.20 and beyond
Keith,
Please consider the attached patch for inclusion in all future versions
of the modutils depmod program for compatiblity with RedHat and
RedHat derived Linux distributions. This patch only requires
4 very short changes to depmod.c as opposed to thousands of
changes necessary in anaconda and other RedHat compatible
programs and scripts to work with your standard depmod
programs without these changes.
Thanks
Jeff
--- modutils-2.3.20/depmod/depmod.c.chmou Thu Nov 16 01:40:09 2000
+++ modutils-2.3.20/depmod/depmod.c Wed Nov 22 05:18:09 2000
@@ -188,6 +188,7 @@
static SYMBOL *symavail;
static SYMBOL *maxsyms;
static LIST_SYMBOL *chunk;
+static int ignore_symbol_versions;
static int quiet; /* Don't print errors */
static int showerror; /* Shows undefined symbols */
@@ -1098,7 +1099,9 @@
{"errsyms", 0, 0, 'e'},
{"filesyms", 1, 0, 'F'},
{"help", 0, 0, 'h'},
+ {"ignore-versions", 0, 0, 'i'},
{"show", 0, 0, 'n'},
+ {"system-map", 1, 0, 'm'}, /* backward compatibility, same as 'F' */
{"quiet", 0, 0, 'q'},
{"syslog", 0, 0, 's'},
{"verbose", 0, 0, 'v'},
@@ -1109,7 +1112,7 @@
error_file = "depmod";
- while ((o = getopt_long(argc, argv, "aAb:C:eF:hnqsvVr",
+ while ((o = getopt_long(argc, argv, "aAb:C:eF:him:nqsvVr",
&long_opts[0], NULL)) != EOF) {
switch (o) {
case 'A':
@@ -1132,11 +1135,16 @@
return 0;
break;
+ case 'i':
+ ignore_symbol_versions = 1;
+ break;
+
case 'C':
conf_file = optarg;
break;
case 'F':
+ case 'm':
file_syms = optarg;
break;
Re: [PATCH] modutils 2.3.20 and beyond
On Sun, Nov 26, 2000 at 10:46:35PM +, Alan Cox wrote:
> > + {"ignore-versions", 0, 0, 'i'},
>
> I dont think we should encourage anyone to ignore symbol versions
Anaconda will barf and require over 850+ changes to the scripts without
it. If you look at the patch, you will note that it's a silent switch
that's only there to avoid a noisy error message from depmod. It
actually does nothing other than set a flag that also does nothing.
-m simply maps to -F.
:-)
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/
Re: initdata for modules?
On Mon, Nov 27, 2000 at 09:54:57AM +1100, Keith Owens wrote:
> On Sun, 26 Nov 2000 07:30:44 -0800,
> "Adam J. Richter" <[EMAIL PROTECTED]> wrote:
> > In reading include/linux/init.h, I was surprised to discover
> >that __init{,data} expands to nothing when compiling a module.
> >I was wondering if anyone is contemplating adding support for
> >__init{,data} in module loading, to reduce the memory footprints
> >of modules after they have been loaded.
>
> It has been discussed a few times but nothing was ever done about it.
> AFAIK the savings were not seen to be that important because modules
> occupy complete pages. __init would have to be stored in a separate
> page which was then discarded. It would complicate insmod, rmmod,
> ksymoops and gdb. gdb against the kernel already gets confused by
> vmlinux data that is discarded and gdb has problems with modules at the
> best of times. Definitely 2.5 material, if at all.
One really nice addition to the modutils would be to allow module
dependencies to be stored in the headers of modules. i.e. NetWare
NLMs have a "module depends" field where you can list modules you
have dependencies on, and so does NT with DLL's, and the loader auto
loads these modules when you load any module. What's troublesome
about modutils in their current form is if you don't have a
modules.dep file, insmod isn't smart enough to read the depenency
modules from a binary header, and load them without doing a lot
of needless checking with modprobe. Having to depend on an external
text file for this looks tacky to customers and is error prone.
I understand that it's nice to be able to change modules around
and have the flexibilty to do this dynamically, but since modules
that use this are complied from the kernel, and the kernel
build always knows "who owns the APIs" there's no reason it could
or should not be done this way. i.e.
when loading ppp and it's modules:
slhc
ppp
ppp_deflate
bsd_comp
There's no reason that ppp could not have in it's binary header the
name "slhc" and any other modules it is dependent on so insmod
will load all of them if someone types
insmod ppp_deflate (should trigger load of all these modules). I
know it's works this way if there's a modules.dep file laying
around, but it would be nice for it to work this way without
needing the external text file.
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: [PATCH] modutils 2.3.20 and beyond
On Sun, Nov 26, 2000 at 06:02:35PM -0500, Mohammad A. Haque wrote: > I'd rather have Anaconda changed rather than special casing standard > utils to account for distro handling. Great. Then tell RedHat to rewrite it without the need for these switches. They will say NO. It's a trivial change, and would save me a lot of hours rewriting scripts. I did it once, but if RedHat has standardized on this set of switches, why not add them as alias commands? It's a trivial patch. Jeff > > "Jeff V. Merkey" wrote: > > > > Anaconda will barf and require over 850+ changes to the scripts without > > it. If you look at the patch, you will note that it's a silent switch > > that's only there to avoid a noisy error message from depmod. It > > actually does nothing other than set a flag that also does nothing. > > -m simply maps to -F. > > > > -- > > = > Mohammad A. Haque http://www.haque.net/ >[EMAIL PROTECTED] > > "Alcohol and calculus don't mix. Project Lead >Don't drink and derive." --Unknown http://wm.themes.org/ >[EMAIL PROTECTED] > = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] modutils 2.3.20 and beyond
On Sun, Nov 26, 2000 at 04:15:02PM -0700, Tom Rini wrote: > On Sun, Nov 26, 2000 at 05:03:34PM -0700, Jeff V. Merkey wrote: > > > Great. Then tell RedHat to rewrite it without the need for these switches. > > They will say NO. It's a trivial change, and would save me a lot of hours > > rewriting scripts. I did it once, but if RedHat has standardized on this > > set of switches, why not add them as alias commands? It's a trivial > > patch. > > I hate to jump in here in the middle of a perfectly good argument but I'd like > to point out a few things: > a) If RedHat/RedHat-like distros needs these changes they can include this > patch. The plus side is it won't piss off the people that seem to care and > don't use said distros the down side is that if/when another security update > comes out people will have to hope this patch applies easily still, if they > update themselves. > b) Are these switches which used to be valid in modutils 2.3.x? If so, why? > It makes perfect sense to keep this patch around until modutils 2.4 (or 2.5 > if modutils version is still supposed to match kernel version). If these > are old modutils 2.2.x switches, see part a). > And c) Why does it matter if RedHat/etc would have to adapt their scripts. > There's always part a, or what debian does for stable sometimes, backporting > fixes. Or even lots of sed & awk magic. Oh well. Look like %patch -p1 in the rpm for now. Jeff > > -- > Tom Rini (TR1265) > http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] modutils 2.3.20 and beyond
On Mon, Nov 27, 2000 at 10:23:08AM +1100, Keith Owens wrote: > On Sun, 26 Nov 2000 16:36:55 -0700, > "Jeff V. Merkey" <[EMAIL PROTECTED]> wrote: > >Keith, > > > >Please consider the attached patch for inclusion in all future versions > >of the modutils depmod program for compatiblity with RedHat and > >RedHat derived Linux distributions. > > I have a big problem with Redhat. They make incompatible changes to > utilities, do not feed patches back to maintainers then expect the rest > of the world to follow their lead. The -i and -m flags to modutils are > not the only example, I recently found IA64 and Sparc patches they had > added to modutils code and not bothered to tell me. Other distributors > are much better about sending me patches, Debian and SuSe in particular > do the right thing. > > Since "-F System.map" in modutils is equivalent to "-m System.map -i" > and works on all distributions, not just Redhat, the "-m -i" patch is > unnecessary. Consider this my protest against bad habits by > distributors, they created the mess with their lack of communication > and they have to fix it. Well Keith, I will never fail to post back changes to you, as evidenced by the fact I did send you one. Anconda is open sourced, and as such, is no longer owned by any distributor. The question is whether to diverge it from theirs. I would like to not do this, since, as you point out, it generates changes back the other way. It's your call. I can keep the patch around because I really don't want to diverge anaconda any more than I have to. At some point, perhaps they will get changes to you more timely. :-) 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/
Re: initdata for modules?
On Mon, Nov 27, 2000 at 10:45:34AM +1100, Keith Owens wrote: > On Sun, 26 Nov 2000 17:01:35 -0700, > "Jeff V. Merkey" <[EMAIL PROTECTED]> wrote: > >insmod ppp_deflate (should trigger load of all these modules). I > >know it's works this way if there's a modules.dep file laying > >around, but it would be nice for it to work this way without > >needing the external text file. > > There is a clean split between modprobe and insmod, modprobe is the > high level command that does all the fancy checking for inter module > dependencies, handling aliases and extracting options from > modules.conf. insmod is the low level command that does exactly what > you tell it to do, no more, no less. The only smarts that insmod has > is the ability to take a module name without '/' and find it using the > patchs in modules.conf. That split between high and low level commands > is too useful to contaminate. > > modules.conf already supports "above" and "below" commands for > non-standard dependencies. The problem of not having a module.dep on > the first boot of a new kernel was addressed in kernel 2.4.0-test5 or > thereabouts, make modules_install runs depmod to build modules.dep > ready for the first boot. Good. I am glad this is being addressed. 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/
Re: [PATCH] modutils 2.3.20 and beyond
On Sun, Nov 26, 2000 at 04:16:26PM -0800, David Ford wrote: > "Jeff V. Merkey" wrote: > > > On Sun, Nov 26, 2000 at 06:02:35PM -0500, Mohammad A. Haque wrote: > > > I'd rather have Anaconda changed rather than special casing standard > > > utils to account for distro handling. > > > > Great. Then tell RedHat to rewrite it without the need for these switches. > > They will say NO. It's a trivial change, and would save me a lot of hours > > rewriting scripts. I did it once, but if RedHat has standardized on this > > set of switches, why not add them as alias commands? It's a trivial > > patch. > > Then let RedHat maintain their version of modutils. RedHat isn't the > standard, nor should RedHat dictate to authors, nor should other distributions > and persons be affected by RedHat's methods. > > If you don't like it, replace your depmod with a script that strips that flag > before calling the original depmod. Anaconda is open sourced, so it's not technically tied to any one distributor any more Jeff > > -d > Content-Description: Card for David Ford - 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: initdata for modules?
On Sun, Nov 26, 2000 at 03:47:30PM -0800, Adam J. Richter wrote:
> Keith Owens <[EMAIL PROTECTED]> wrote:
> >"Adam J. Richter" <[EMAIL PROTECTED]> wrote:
> >>In reading include/linux/init.h, I was surprised to discover
> >>that __init{,data} expands to nothing when compiling a module.
> >>I was wondering if anyone is contemplating adding support for
> >>__init{,data} in module loading, to reduce the memory footprints
> >>of modules after they have been loaded.
>
> >It has been discussed a few times but nothing was ever done about it.
> >AFAIK the savings were not seen to be that important because modules
> >occupy complete pages. __init would have to be stored in a separate
> >page which was then discarded. [...]
>
> No, you could just discard the part after the next page
> boundary. The expected savings would be about the same, since
> the cases where the original code had just creeped over a page
> boundary in many cases would result in dropping more memory savings
> that the actual init size, from dropping those unused bytes
> between the very end of the init section and the end of that page.
> I say "about" the same becuase the distribution of text and data
> sizes is not uniformly random within some fixed interval.
>
> Since you would not have to bump the start address of a
> section to the next page boundary, I wonder if it would still
> complicate insmod et al.
>
> In case there is any confusion, I am not suggesting that
> this should go into the stock 2.4.0 releases.
>
> However, I do find it helpful in allocating my time to
> cosider that saving one page by something like this or by enhancing
> gcc's variable placement saves as much space as 1024 eliminations
> of "= 0" or "= NULL" static variable initializations.
Microsoft drivers have an .INIT code section that is initialization
ccode that get's chunked after it's loaded. Their model allows
memory segments to be defined as DISCARDABLE, which tells the loader
to chunk them after they get loaded in portable executable format.
If ELF has something like it, perhaps it should go in the loader?
Jeff
>
> Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
> [EMAIL PROTECTED] \ / San Jose, California 95129-1034
> +1 408 261-6630 | g g d r a s i l United States of America
> fax +1 408 261-6631 "Free Software For The Rest Of Us."
> -
> 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: initdata for modules?
On Mon, Nov 27, 2000 at 01:06:04PM +1100, Keith Owens wrote: > On Sun, 26 Nov 2000 19:49:43 -0700, > "Jeff V. Merkey" <[EMAIL PROTECTED]> wrote: > >Microsoft drivers have an .INIT code section that is initialization > >ccode that get's chunked after it's loaded. Their model allows > >memory segments to be defined as DISCARDABLE, which tells the loader > >to chunk them after they get loaded in portable executable format. > > The loader is insmod, which does all its own reloaction and loading. > The problem is that ancillary tools like ksymoops, gdb, kdb and > possibly others do not expect sections to be discarded after load. > Adding the feature to insmod is fairly easy, fixing the ancillary tools > to understand that some sections are discarded after load is a bit > harder. Debugging is particularly messy, when an oops occurs how do we > tell if the __init data been discarded yet or not? > > I have added this to my investigation list for modutils, ksymoops and > kdb 2.5, no promises. :-) 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/
Re: [PATCH] modutils 2.3.20 and beyond
On Mon, Nov 27, 2000 at 02:11:49AM +, Alan Cox wrote: > > > Anaconda will barf and require over 850+ changes to the scripts without > > > it. If you look at the patch, you will note that it's a silent switch > > > that's only there to avoid a noisy error message from depmod. It > > > actually does nothing other than set a flag that also does nothing. > > > -m simply maps to -F. > > > > It's still a bad precedent. Anaconda should have been written correctly in > > the first place. > > I don't know if its an Anaconda issue or a limitation in the tools. Keith is > the modutils maintainer and its up to the Anaconda hackers to prove to him that > he has a problem so I think he is absolutely right in refusing to change it > until that is proven Oddly, the tools already provide the capability needed by anaconda, just not in the format the anaconda scripts and code expect. i.e., anaconda is using -m in place of -F, and somewhere down the line someone needed to force depmod checks of modules against mismatched kernels (???) which is probably left over from some point when RedHat was shipping default kernels "naked" (without modversions). That's the only justification I can see for having -i at all, and since I come from a binary compatible world, I can kindof understand why someone would have needed this to support loading of binary modules accross versions (before modversions became widely used). I don't know how to take the "anaconda hacker" moniker. 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/
syslinux and 2.4.0 initrd size problems
I am having trouble getting a 2.4 vmlinuz (bzImage) and initrd image onto a 1.44 floppy with all the new stuff. Even a stipped down kernel compiled under 2.4 is @ 600K compressed, and I need about 800K for the initrd image. I noticed that syslinux has some comments about not allowing initrd to span media. I there something more current that does or will allow me to load the inittrd off a CD-ROM device (with vmlinuz and syslinux on the floppy). I know how to do this with GRUB (Grand Unified Boot Loader), but I want to use syslinux if possible. Thanks 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/
Re: syslinux and 2.4.0 initrd size problems
On Sun, Nov 26, 2000 at 08:22:54PM -0800, H. Peter Anvin wrote: > Why are you posting this to the kernel list? See the SYSLINUX > documentation for the SYSLINUX mailing list address. Never mind. I am rewriting the install init program instead and restructuring the driver organization to do what I need. 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/
Re: syslinux and 2.4.0 initrd size problems
On Mon, Nov 27, 2000 at 09:29:08AM -0800, Michael Peddemors wrote: > Happily using initrd on a 1.44 floppy here, and there should be no reason why > you can't use it for a CDROM distro as well, you can have syslinux on the > CDROM too... I believe their is a a syslinux mailing list to check if you > have problems, and he has recently released updated versions of syslinux. I've got it working here too, but not with an initrd image and vmlinuz image that's bigger than the floppy. 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/
2.2.18-23 w/Frame Buffer (LEVEL IV)
A level IV issue in 2.2.18-23. With frame buffer enabled, upon boot, the OS is displaying four penguin images instead of one penguin in the upper left corner of the screen. Looks rather tacky. Also puts the VGA text mode default into mode 274. Is this what's supposed to happen? 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/
Re: 2.2.18-23 w/Frame Buffer (LEVEL IV)
Sven Koch wrote: > > On Mon, 27 Nov 2000, Jeff V. Merkey wrote: > > > A level IV issue in 2.2.18-23. With frame buffer enabled, upon boot, > > the OS is displaying four penguin images instead of one penguin in the > > upper left corner of the screen. Looks rather tacky. Also puts the VGA > > text mode default into mode 274. Is this what's supposed to happen? > > Let me guess: it's a 4 cpu smp system? Correct. I take it them this is supposed to happen. Jeff > > c'ya > sven > > -- > > The Internet treats censorship as a routing problem, and routes around it. > (John Gilmore on http://www.cygnus.com/~gnu/) - 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: Broken NTFS
On Wed, Nov 29, 2000 at 06:33:36AM -0800, Joseph K. Malek wrote: > Hi all, > > I have a broken NTFS, due to my own mistake of mounting the > partition RW and moving a file instead of copying itI've been poking > around for an NTFS editing tool; only to find that this is easier said > than done. Does anyone have an NTFS repair tool for winnt 4 (I already > have the ddk), or any idea where I can find one? > I have a tool that will repair the damage caused to an NTFS volume by Linux. Questions: 1. Did you boot NT on the drive and did it become RAW? 2. Have you run checkdisk against the drive, and if so, what happened? If you answer yes to #1, you have probably already experienced permanent data loss on the device. Older NTFS versions on Linux would make changes to the MFT without clearing the old journal file, then leave the drive marked as "clean" to NT. What can happen in this case is that NTFS on W2K will see the logfile, then attempt to roll out the changes. In NT the MFT is updated real time and the logfile is transacted after the fact. This can (but not always) cause massive data loss on NTFS drives. Anton has fixed a lot of these issues on the newer code, but Linux NTFS is still a very dangerous piece of software to use R/W (R/O works OK). Do you need this tool? Jeff > thanks in advance! > > -- > > .oO0Oo.|.oO0Oo.|.oO0Oo.|.oO0Oo.|.oO0Oo.|.oO0Oo. > This message was made from 100% post-consumer > recycled magnetic domains. No binary trees were > destroyed to make it. > > - > 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: Fasttrak100 questions...
On Wed, Nov 29, 2000 at 09:08:30PM +0100, Henning P . Schmiedehausen wrote: > No. > > If I modify the kernel or any other GPL software for my personal use > and give it to no one, I am _not at all_ forced to make it public. > > Only if I distribute a compiled kernel or any other program under GPL, > then I must give also the sources on request (!) and may not put any > restrictions on your redistribution of these sources. Only thing that > you must obey is again the GPL. > > I use heavily patched kernels with lots of inhouse-stuff on a regular > base for my inhouse use and there is _no_ way for you to even get a > glimpse at it. I don't give this to anyone, it's all just my personal > stuff. Depending on the terms of your use of the code, the Copyright holder can obtain an order compelling you to hand over the code from a State or US District Court Judge, if you are using it under the terms of the GPL and fail to provide the modifications upon request, and you are shown to be "converting" business opportunities to your own benefit with it, GPL or no. That being said, the party seeking the order would be required to show irreparable harm, which in this case, could be shown (you stated you intend to act in bad faith and breach the terms of the license). I do not believe a Copyright holder, as I understand the GPL, would be able to stop you from redistributing your changes and/or selling them. The GPL would grant you this right. However, the copyright holder could obtain an order forcing your compliance to the license in the US (and even in some foreign countries, but not all), and could also simply sue you for "conversion", then issue a Subpeona Dues Tecum, and obtain the code via discovery uver F.R.C.P./U.C.C.P., and you would be ordered to produce it, or face criminal contempt charges. If there's a finding of bad faith (i.e. you knew you were violating the license and did it anyway), the judge could also hit you for punitive damages. Actually you are part right and part wrong. If the terms of the license require to return "derivative works" (which I believe the GPL does), you have an obligation to provide these changes upon request. It's also just plain old good manners. :-) Jeff > > You can't force me to give you a copy of my blafoo driver until I > chose to either release it to the public in which case I must put it > under GPL as it contains GPLed code or distribute a binary version to > a customer, which then in turn has the right to request the source > from me and (after he got it, because I am bound by GPL to give it to > him), distribute it freely as this right is granted to him by GPL. You have balls a big as mine. > > I am even allowed to erase my sources without making them ever public. > > Please read the GPL: > > --- cut --- > Activities other than copying, distribution and modification are not modification >>> you're nailed. :-) Jeff > covered by this License; they are outside its scope. The act of > running the Program is not restricted, and the output from the Program > --- cut --- > > I don't distribute the software. I just run it. > > --- cut --- > 2. You may modify your copy or copies of the Program or any portion > of it, thus forming a work based on the Program, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > --- cut --- > > I chose not to copy and distribute these modified programs which is > perfectly covered by my license which I got when obtaining the > sources. > > Anything else would mean that I can send E-Mail to Linus Torvalds > every five minutes and request a verbatim copy of his current hacking > kernel tree as it is under GPL, which he is the forced to give to me > because of the GPL. This would be utter nonsense. > > Regards > Henning > > > On Wed, Nov 29, 2000 at 11:53:59AM -0800, Dr. Kelsey Hudson wrote: > > On Sat, 25 Nov 2000, Henning P. Schmiedehausen wrote: > > > > > No, it does not. Distributing does. You will never get this right. You > > > can compile into your kernel anything you like as long as you don't > > > give it away. > > > > You are wrong: If you modify the kernel you have to make it available for > > anyone who wishes to use it; that's also in the GPL. You can't add stuff > > to it and then not distribute it, that's in violation. > > > > Kelsey Hudson [EMAIL PROTECTED] > > Software Engineer > > Compendium Technologies, Inc (619) 725-0771 > > --- > > -- > Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer > INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] > > Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] > D-91054 Buckenhof Fax.: 09131 / 50654-20 > - > To unsubsc
Re: Fasttrak100 questions...
On Thu, Nov 30, 2000 at 10:14:47AM -0500, Christopher Friesen wrote: > "Jeff V. Merkey" wrote: > > > > On Wed, Nov 29, 2000 at 09:08:30PM +0100, Henning P . Schmiedehausen wrote: > > > > I use heavily patched kernels with lots of inhouse-stuff on a regular > > > base for my inhouse use and there is _no_ way for you to even get a > > > glimpse at it. I don't give this to anyone, it's all just my personal > > > stuff. > > > > Depending on the terms of your use of the code, the Copyright holder > > can obtain an order compelling you to hand over the code from a > > State or US District Court Judge, if you are using it under the terms > > of the GPL and fail to provide the modifications upon request, and you > > are shown to be "converting" business opportunities to your own > > benefit with it, GPL or no. > > I think you should re-read the GPL. You only have to provide source to > people to whome you have distributed your new binaries, and you only > have to provide that source if you are asked for it. If you have some > code that you have written that is based on GPL'd code, and you are the > only person that ever runs the binaries, then there is no obligation for > you to make your code available to anybody. Depends on what terms the code is provided under. Using GPL code in a for profit enterprise and distributing it to customers does require that the changes be provided upon request. I have read the GPL, and I've had a lot of lawyers around here read and analyze it too. :-) Jeff > > Only once you distribute the software to others do you have to make the > code available, and even then you only have to make it available to > those who have the binaries. Of course, they can then turn around and > do whatever they feel like with it, but thats a different issue. > > > -- > 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/ - 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: Fasttrak100 questions...
On Thu, Nov 30, 2000 at 01:09:37PM -0500, Christopher Friesen wrote: > "Jeff V. Merkey" wrote: > > > > On Thu, Nov 30, 2000 at 10:14:47AM -0500, Christopher Friesen wrote: > > > > I think you should re-read the GPL. You only have to provide source to > > > people to whome you have distributed your new binaries, and you only > > > have to provide that source if you are asked for it. If you have some > > > code that you have written that is based on GPL'd code, and you are the > > > only person that ever runs the binaries, then there is no obligation for > > > you to make your code available to anybody. > > > > Depends on what terms the code is provided under. Using GPL code in a > > for profit enterprise and distributing it to customers does require > > that the changes be provided upon request. I have read the GPL, and > > I've had a lot of lawyers around here read and analyze it too. > > > > :-) > > Well of course this is the case. I specifically said that I am the only > one that ever ran the binaries. Once you start distributing it to other > people, then they can request the source additions/modifications and you > are obligated to provide it. > > Theoretically you could use software based on GPL'd code all throughout > a for-profit corporation and make boatloads of money using that > software. As long as you don't distribute it to customers outside the > company, and as long as none of the employees using it ask for the > source and distribute it outside the company, nobody outside that > corporation has any right to the source even though it is being used for > profit. I'm not certain this is technically correct, but I think it would be worth having some folks here investigate this secnario. Jeff > > -- > 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: Oops in 2.2.18 with pppd dial in server
On Fri, Dec 01, 2000 at 12:46:18PM +, Alan Cox wrote: > > I was able to reproduce this oops with a somewhat more reliable ksymoops (I was >ready for this nasty bug this time). Looks like the problem is in the sockets > > code. > > The traces so far all match one description , this one included. Its the > 'something scribbled a while ago and I just walked the list and found it' > > Is your ppp module getting loaded/unloaded a lot. Im wondering if we have Humm. The kernel ppp module is not getting unloaded. I am using both the pppd 2.3.11 and pppd-mppe 2.3.10 versions (pppd-mppe has CHAP-80 and MPPE patched into the code). The user space module does load and unload a lot due to all the testing we are doing. I took the CWorthy ncurses interface I wrote for the NWFS tools, and am using it to write a pppconfig utility that handles modem setup, inittab, mgetty, options.ttyX, etc. so setting up a dial-in server will be as easy with IPX and IP as it is in NT. I have also noticed that pppd is not "kicking" modprobe -v the way it probably should, and the ppp kernel modules have to be loaded and configured manually. Jeff > a module related race. That would explain why folks running large ppp dialin > servers simply dont see any problems > > - > 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: Fasttrak100 questions...
On Sat, Dec 02, 2000 at 06:46:59PM -0500, Theodore Y. Ts'o wrote: >Date: Sat, 2 Dec 2000 17:18:43 + (GMT) >From: Alan Cox <[EMAIL PROTECTED]> > > Well, it's not up to just me, given that Linus also has his copyright on > the code (although I doubt there's more than a few lines which are > originally his). There are some other people who have contributed code > to the serial driver in the past, although most have probably not given > me more than a dozen lines of code or so, which seems to be the > (completely untested in court) standard which the FSF uses to decide > whether or not they need to get formal legal papers signed. > > The legal issues are also incredibly murky, that's "Merkey" > since the customers create > the derived work, and issues of intent aside, you can't necessarily use > intent to change the legal definition of "derived work". (Be glad; > although it can be used to create a loophole in GPL, just meditate a > while on what the MPAA could do with such an "intent" argument before > you decide whether or not it's a good thing. Or think what Microsoft > could do if they could make their EULA's as infectious as the GPL with > the "intent" argument.) The whole dynamic linking argument is a very > slippery slope; where do you draw the line? Does a shell script which > calls a GPL program get infected? What about a propietary C program > which makes a system() call to invoke a GPL'ed bash? What about an RPC > call across the network? What about a GNOME Corba interface? Is it OK > if it's on separate machines, but are they considered a single program > if the CORBA client and server are on the same machine, since now they > share the same VM? Under the "Doctrine of Inevitable Disclosure" even looking at GPL code and using techniques it contains would contaminate anything someone works on. This doctrine put forward two concepts that have been used in trade secret cases to justify injunctions and non-competes in areas of IP pollution -- negative knowledge and inevitable misappropriation. The argument goes something like this. Negative knowledge is defined as knowing what techniques do not work (as opposed to what techniques do work). In the course of development of a piece of software, there are many "blind alleys" and "false starts" that are encountered as an individual uses trial and error to perfect whatever piece of software he is writing. Over time, the person learns what approaches are blind alleys and which work. This knowledge becomes imprinted into the actual thinking processes of this person. Source code can also contain notes and comments about what does not work, and what does work. Someone reading this source code would then incorporate these ideas and knowledge into their thinking processes. Companies spend lots of money paying engineers to develop software, and this "negative knowledge", under the doctrine of inevitable disclosure is legally the property of an employer since they paid an engineer to experiment and learn it. This is how companies are able to get non-compete court orders against employees in trade secret lawsuits -- they argue that noone is going to go down a development path using ideas or approaches they know do not work. This argument goes on to state that if two engineers, one who had access to a piece of code vs. one who did not were to start at the same time working on the same problem, the person who had access to the code would finish first because he would "inevitably use" the knowledge gained from access to the source code. Let's say for example two engineers wanted to write a new Linux-like replacement. One of them had access to ftp.kernel.org and the other did not. Which one of the engineers would finish first? Obviously the one with access to ftp.kernel.org would finish first and would not have had to use trial and error to get all the IOCTL calls working, etc. The engineer without source code access would take longer, perhaps by a factor of years, to complete the same project. Under this argument, it is argued that the engineer who had source code access "inevitably used" negative knowledge he gained from his study of the Linux sources. Absent the vague descriptions of what a "derivative work" is in the GPL, it could be argued that conversion of any knowledge contained in GPL code is a "derivative work". There are a lot of big software companies who believe this and fear application of the doctrine of inevitable disclosure relative to GPL code. Novell and Microsoft both do not even allow employees to bring GPL code into the building -- period -- for fear that someone will attempt to file a claim that they have "converted" GPL code and created derivative works that may have contaminated non-GPL code projects. Novell has an official standing policy barring employees from using GPL code. That's why all the Linux work for NetWare is done in the India development cente
Re: Fasttrak100 questions...
On Sat, Dec 02, 2000 at 06:21:26PM -0700, Jeff V. Merkey wrote: > On Sat, Dec 02, 2000 at 06:46:59PM -0500, Theodore Y. Ts'o wrote: > >Date:Sat, 2 Dec 2000 17:18:43 + (GMT) > >From: Alan Cox <[EMAIL PROTECTED]> > > > > Well, it's not up to just me, given that Linus also has his copyright on > > the code (although I doubt there's more than a few lines which are > > originally his). There are some other people who have contributed code > > to the serial driver in the past, although most have probably not given > > me more than a dozen lines of code or so, which seems to be the > > (completely untested in court) standard which the FSF uses to decide > > whether or not they need to get formal legal papers signed. > > > > The legal issues are also incredibly murky, > > that's "Merkey" > > > since the customers create > > the derived work, and issues of intent aside, you can't necessarily use > > intent to change the legal definition of "derived work". (Be glad; > > although it can be used to create a loophole in GPL, just meditate a > > while on what the MPAA could do with such an "intent" argument before > > you decide whether or not it's a good thing. Or think what Microsoft > > could do if they could make their EULA's as infectious as the GPL with > > the "intent" argument.) The whole dynamic linking argument is a very > > slippery slope; where do you draw the line? Does a shell script which > > calls a GPL program get infected? What about a propietary C program > > which makes a system() call to invoke a GPL'ed bash? What about an RPC > > call across the network? What about a GNOME Corba interface? Is it OK > > if it's on separate machines, but are they considered a single program > > if the CORBA client and server are on the same machine, since now they > > share the same VM? BTW, for those legal folks who also demand I post case law citations, please see the Pesico vs. (I forget the guys name) case. Just get on Westlaw, and look up "Pepsico". This is the case where this doctrine was created and applied by a state judge. The case was upheld, and has been used all over the US since then to shaft departing employees from big software/hardware companies. Jeff > > Under the "Doctrine of Inevitable Disclosure" even looking at GPL code > and using techniques it contains would contaminate anything someone > works on. This doctrine put forward two concepts that have been > used in trade secret cases to justify injunctions and non-competes > in areas of IP pollution -- negative knowledge and inevitable > misappropriation. > > The argument goes something like this. Negative knowledge is defined as > knowing what techniques do not work (as opposed to what techniques > do work). In the course of development of a piece of software, > there are many "blind alleys" and "false starts" that are encountered > as an individual uses trial and error to perfect whatever piece > of software he is writing. Over time, the person learns what > approaches are blind alleys and which work. This knowledge becomes > imprinted into the actual thinking processes of this person. > > Source code can also contain notes and comments about what does not > work, and what does work. Someone reading this source code would > then incorporate these ideas and knowledge into their thinking > processes. Companies spend lots of money paying engineers to > develop software, and this "negative knowledge", under the > doctrine of inevitable disclosure is legally the property > of an employer since they paid an engineer to experiment and > learn it. This is how companies are able to get non-compete > court orders against employees in trade secret lawsuits -- they > argue that noone is going to go down a development path using ideas > or approaches they know do not work. This argument goes on > to state that if two engineers, one who had access to a piece of > code vs. one who did not were to start at the same time working > on the same problem, the person who had access to the code would > finish first because he would "inevitably use" the knowledge gained > from access to the source code. > > Let's say for example two engineers wanted to write a new Linux-like > replacement. One of them had access to ftp.kernel.org and the other > did not. Which one of the engineers would finish first? Obviously > the one with access to ftp.kernel.org would finish first and > would not have had to use trial and error to get all the IOCTL call
Re: Fasttrak100 questions...
On Sat, Dec 02, 2000 at 10:42:29PM -0500, Theodore Y. Ts'o wrote: >Date: Sat, 2 Dec 2000 18:21:26 -0700 >From: "Jeff V. Merkey" <[EMAIL PROTECTED]> > >Under this argument, it is argued that the engineer who had source >code access "inevitably used" negative knowledge he gained from >his study of the Linux sources. Absent the vague descriptions of >what a "derivative work" is in the GPL, it could be argued that >conversion of any knowledge contained in GPL code is a "derivative >work". > > That's bullshit. Copyright law very clearly states that it protects the > fixation of an idea in a medium, and that copyright explicitly does not > protect the idea itself. The concept of what is a derived work is very State Laws may be controlling if they involve contracts. It has nothing to do with Copyright Law, but with the terms of license for someone's code. I've seen this crap applied. I've even been on the receiving end of it, and been enjoined from working on PUBLIC GPL CODE for 18 months because of an AGREEMENT and not copyright laws. > clearly understood, and there have been a lot of court cases to define Under inevitability, the neural impules in your brain can be ruled to be a derivative work. Believe me, I am not arguing for the doctrine, but informing you of it's existence and the broad scope it has in IP cases. > this precedent. (My understanding is that in realm of music 7 notes in > sequence, if copied, is prima facie evidence that there is a derived > work. Not 5 notes, and not 8 notes, but seven notes. Gotta love those > lawyers at work. Aren't you glad they settled that?) > >Personally, I think the doctrine is one of the most evil fucking things >in existence, legal opponents call it "the doctrine of intellectual >slavery" because it has the affect under the law to be able to convert >simple NDA agreements into non-compete agreements, and I've seen it >used this way. > > That's a different matter. If you use NDA and Trade secret law, then > yes, might be able to enslave programmers using such a law. However > most courts have strict limits to how far they will take non-compete > arguments, and if an NDA turned into a non-compete, past a certain point The legal limit is 18 months in most states. This "I have a right to make a living argument" only holds water if the other side refuses to post a bond. If they post a large enough bond, a court WILL rule in favor of inevitability if they make a good case for it. (The bond required to keep me from programming for 18 months cost Novell $10,000,000.00.) > they will say that a person has a right to earn a living. > Fortunately most judges will apply some amount of common sense, even US Judges are pontius pilate's all -- with hearts as black as the robes they wear. They don't care about you, or your rights. Remember, almost all judges are lawyers who are too old or to incompetent to practice law so they get themselves an appointment. Most of them were crooked lawyers who went into politics (which is how a lawyer gets made into a judge, BTW, he goes into politics). > despite their law school training. In any case, the GPL doesn't involve > NDA's or Trade Secrets, so saying that this doctrine could be used to It has to do with contract law, which is what the doctrine of inevitability is all about. Trade secrets have nothing to do with it, it's a question of knowledge gained via access to code through some form of agreement. In employment situations, it's a trade secret agreement, here in Linux, it's a GPL agreement. > contaminate non-GPL code simply by having people look at GPL code is > bullshit. I argued that looking at Novell Public Code under their form of GPL would not contaminate -- a court ruled otherwise. The court ruled that under inevitability, public code on Novell's website and slides presented at Brianshare, even though they were public, had the affect of contaminating our internal projects under this doctrine. You don't want to kill all the lawyers, you want to kill all the judges -- it was a judge that came up with this inevitability doctrine in the first place :-) 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/
Re: [patch] O_SYNC patch 3/3, add inode dirty buffer list support to ext2
On Thu, Nov 23, 2000 at 12:01:35PM +, Stephen C. Tweedie wrote: > Hi, > > On Wed, Nov 22, 2000 at 11:54:24AM -0700, Jeff V. Merkey wrote: > > > > I have not implemented O_SYNC in NWFS, but it looks like I need to add it > > before posting the final patches. This patch appears to force write-through > > of only dirty inodes, and allow reads to continue from cache. Is this > > assumption correct > > Yes: O_SYNC is not required to force reads to be made from disk. > SingleUnix has an "O_RSYNC" option which does that, but O_SYNC and > O_DSYNC don't imply that. Cool. ORACLE is going to **SMOKE** on EXT2 with this change. Jeff > > Cheers, > Stephen - 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: Phantom PS/2 mouse persists..
On Sun, Dec 03, 2000 at 06:27:52PM +, Alan Cox wrote: > > Unfortunately, 2.2.18pre24 is still convinced that I have a PS/2 mouse > > attached to my machine. > > I've fixed the major case. I can see no definitive answer to the other ghost > PS/2 stuff (except maybe USB interactions). I take it like the others 2.4test > also misreports a PS/2 mouse being present. > > Anyway I think its no longer a showstopper for 2.2.18. Someone with an affected > board can piece together the picture I see it on pre18-23 but pre18-24 seems to be fixed. I need to test with the anaconda installer, since I an still using a pre18-23 boot kernel for the install. 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: Phantom PS/2 mouse persists..
On Sun, Dec 03, 2000 at 02:45:58PM -0700, Jeff V. Merkey wrote: > On Sun, Dec 03, 2000 at 06:27:52PM +, Alan Cox wrote: > > > Unfortunately, 2.2.18pre24 is still convinced that I have a PS/2 mouse > > > attached to my machine. > > > > I've fixed the major case. I can see no definitive answer to the other ghost > > PS/2 stuff (except maybe USB interactions). I take it like the others 2.4test > > also misreports a PS/2 mouse being present. > > > > Anyway I think its no longer a showstopper for 2.2.18. Someone with an affected > > board can piece together the picture > > > I see it on pre18-23 but pre18-24 seems to be fixed. I need to test with the > anaconda installer, since I an still using a pre18-23 boot kernel for > the install. > > Jeff I just tested 2.2.18-24 as a boot kernel with anaconda -- works great -- mouse problem on PS/2 system is nailed. New problem, BTW. With Frame buffer enabled, a system here with an older S3 video card has some sickness with the mouse (???). The mouse is a giant 2" x 2" block of wavy lines. 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/ - 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: Phantom PS/2 mouse persists..
On Sun, Dec 03, 2000 at 05:42:03PM -0500, Steven N. Hirsch wrote: > On Sun, 3 Dec 2000, Jeff V. Merkey wrote: > > > > On Sun, Dec 03, 2000 at 06:27:52PM +, Alan Cox wrote: > > > > > > > > I've fixed the major case. I can see no definitive answer to the other ghost > > > > PS/2 stuff (except maybe USB interactions). I take it like the others 2.4test > > > > also misreports a PS/2 mouse being present. > > > > > > > > Anyway I think its no longer a showstopper for 2.2.18. Someone with an affected > > > > board can piece together the picture > > > I just tested 2.2.18-24 as a boot kernel with anaconda -- works great -- > > mouse problem on PS/2 system is nailed. > > I always seem to own the wierd hardware. I agree the mouse > mis-detection isn't a showstopper - just damn annoying. > > FWIW, USB isn't compiled into the kernel in question. Yes it is. I am also seeing compile problems. I will post to a new subject since they are not mouse related, but IPVS related. Jeff > > Steve > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.18-24 with IPVS patch has compile errors
With the 2.2.17 IPVS patch applied to 2.2.18-24, I am seeing the following compile errors. -D__KERNEL__ -I/usr/src/ute/BUILD/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -D__SMP__ -pipe -fno-strength-reduce -m386 -DCPU=386 -DMODULE -DMODVERSIONS -include /usr/src/ute/BUILD/linux/include/linux/modversions.h -c -o emd.o emd.c cc -D__KERNEL__ -I/usr/src/ute/BUILD/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -D__SMP__ -pipe -fno-strength-reduce -m386 -DCPU=386 -DMODULE -DMODVERSIONS -include /usr/src/ute/BUILD/linux/include/linux/modversions.h -c -o check.o check.c cc -D__KERNEL__ -I/usr/src/ute/BUILD/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -D__SMP__ -pipe -fno-strength-reduce -m386 -DCPU=386 -DMODULE -DMODVERSIONS -include /usr/src/ute/BUILD/linux/include/linux/modversions.h -c -o fsync.o fsync.c touch: /usr/src/ute/BUILD/linux/include/linux/sdladrv.h: No such file or directory make[2]: *** No rule to make target `/usr/src/ute/BUILD/linux/include/linux/sdlasfm.h', needed by `sdladrv.o'. Stop. make[2]: *** Waiting for unfinished jobs make[2]: *** [/usr/src/ute/BUILD/linux/include/linux/sdladrv.h] Error 1 shell-init: could not get current directory job-working-directory: could not get current directory The IPVS patch is also attached. They would seem to be unrelated, but 2.2.18-23 builds clean with this patch. Jeff ipvs-0.9.16-2.2.17.patch.gz
Re: Phantom PS/2 mouse persists..
On Mon, Dec 04, 2000 at 12:49:47AM +0100, Daniel Roesen wrote: > On Sun, Dec 03, 2000 at 10:24:19AM -0500, Steven N. Hirsch wrote: > > Unfortunately, 2.2.18pre24 is still convinced that I have a PS/2 mouse > > attached to my machine. > > Nod. Which board? I'm seeing the problem with Asus CUWE. Number Nine 9FX 772. Jeff > > > Best regards, > Daniel > - > 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: [resync?] Re: corruption
On Sun, Dec 03, 2000 at 05:45:57PM -0500, Alexander Viro wrote: > > > On Mon, 4 Dec 2000, Andrew Morton wrote: > > > Sorry, it's still failing. It took three hours. > > Yes. For one thing, original was plain wrong wrt locking (lru_list_lock > should be held). For another, it does not take care of metadata. And > that's way more serious. What really happens: > > ext2_truncate() got a buffer_head of indirect block that is going to > die. Fine, we release the blocks refered from it and... do bforget() > on our block. Notice that we are not guaranteed that bh will actually > die here. buffer.c code might bump its ->b_count for a while, it might > be written out right now, etc. As the result, bforget() leaves the > sucker alive. It's not a big deal, since we will do unmap_underlying_metadata() > before we write anything there (if it will be reused for data) or we'll > just pick the bh and zero the buffer out (if it will be reused for metadata). > > Unfortunately, we also leave it on the per-inode dirty blocks list. Guess > what happens if inode is destroyed, page that used to hold it gets reused > and bh gets finally written? Exactly. > > Suggested fix: void bforget_inode(struct buffer_head *bh) that would > be a copy of __bforget(), except that it would call remove_inode_queue(bh) > unconditionally. And replace bforget() with bforget_inode() in those places > of ext2/inode.c that are followed by freeing the block. > > Comments? I'll do a patch, but I'ld really like to know what had already > gone into the main tree. Linus, could you put the 12-pre4-dont-use on > ftp.kernel.org? Al, I am always amazed at how rapidly you seem to be able to run down some of these file system corruption problems. You seem to understand the interaction of this layer extremely well. :-) 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: 2.2.18-24 with IPVS patch has compile errors
On Sun, Dec 03, 2000 at 05:52:26PM -0700, Jeff V. Merkey wrote: > > > With the 2.2.17 IPVS patch applied to 2.2.18-24, I am seeing the following > compile errors. > > -D__KERNEL__ -I/usr/src/ute/BUILD/linux/include -Wall -Wstrict-prototypes -O2 >-fomit-frame-pointer -fno-strict-aliasing -D__SMP__ -pipe -fno-strength-reduce > -m386 -DCPU=386 -DMODULE -DMODVERSIONS -include >/usr/src/ute/BUILD/linux/include/linux/modversions.h -c -o emd.o emd.c > cc -D__KERNEL__ -I/usr/src/ute/BUILD/linux/include -Wall -Wstrict-prototypes -O2 >-fomit-frame-pointer -fno-strict-aliasing -D__SMP__ -pipe -fno-strength-reduce > -m386 -DCPU=386 -DMODULE -DMODVERSIONS -include >/usr/src/ute/BUILD/linux/include/linux/modversions.h -c -o check.o check.c > cc -D__KERNEL__ -I/usr/src/ute/BUILD/linux/include -Wall -Wstrict-prototypes -O2 >-fomit-frame-pointer -fno-strict-aliasing -D__SMP__ -pipe -fno-strength-reduce > -m386 -DCPU=386 -DMODULE -DMODVERSIONS -include >/usr/src/ute/BUILD/linux/include/linux/modversions.h -c -o fsync.o fsync.c > touch: /usr/src/ute/BUILD/linux/include/linux/sdladrv.h: No such file or directory > make[2]: *** No rule to make target >`/usr/src/ute/BUILD/linux/include/linux/sdlasfm.h', needed by `sdladrv.o'. Stop. > make[2]: *** Waiting for unfinished jobs > make[2]: *** [/usr/src/ute/BUILD/linux/include/linux/sdladrv.h] Error 1 > shell-init: could not get current directory > job-working-directory: could not get current directory > > > The IPVS patch is also attached. They would seem to be unrelated, but > 2.2.18-23 builds clean with this patch. > > Jeff > Update. 2.2.18-24 requires that the patch be applied to 2.2.17 before applying the pre-patch. 2.2.18-23 didn't seem to care about patch order. Got it to build with piranha after switching the patch order. 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/
2.4.0-11 AIC7xxx.o driver barfs on AHA27XX adapter
On a four processor POCA system with dual Fast-SCSI AHA274X/VLB bus controllers I am seeing the following timeout errors right after the sequencer scripts are downloaded and the driver starts polling. It does not happen when compiled in kernel, only when loaded from an initrd image. The root FS is getting mounted properly and probing and loading the driver. aborting command due to timeout: pid 00 scsi 00 channel 00 lun 00 inquiry 00 00 00 ff 00 The machine then hard hangs after it gets this error and has to be powered off in order to reboot it. 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/
Re: 2.4.0-11 AIC7xxx.o driver barfs on AHA27XX adapter
On Sun, Dec 03, 2000 at 06:15:24PM -0700, Jeff V. Merkey wrote: > > > On a four processor POCA system with dual Fast-SCSI AHA274X/VLB bus > controllers I am seeing the following timeout errors right after > the sequencer scripts are downloaded and the driver starts polling. > It does not happen when compiled in kernel, only when loaded from > an initrd image. The root FS is getting mounted properly and > probing and loading the driver. > > aborting command due to timeout: pid 00 scsi 00 channel 00 lun 00 > inquiry 00 00 00 ff 00 > > The machine then hard hangs after it gets this error and has to be > powered off in order to reboot it. I tested 2.2.18-24 with an initrd and works fine on the same hardware, BTW Jeff > > 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: Fasttrak100 questions...
On Tue, Dec 05, 2000 at 01:07:30AM -0600, Brian F. G. Bidulock wrote: > Jeff, > > Have you also seen this applied where it is to the employer's > disadvantage? For example, given that I looked at and worked > with GPL code (say Linux kernel) in University before taking > employment as a programmer that the employer's product is > inevitably contaiminated and no longer a trade secret? Can > a previous employee get an injunction against their former > employer to cease and desist from using this negative knowledge? > > If so, I might have a solution: make the Linux kernel required > reading in University programming classes! Trade Secrets are defined by something called the Uniform Tade Secret Act, which has been adopted in most states. It calls for several points that must be met in order for something to be protected as a "trade secret". Before this act, Muna vs. Microbiological (1964) was one of the landmark cases outlining trade secret law in the US. A lot has happened since Muna, but basically, these are the points. 1. A trade secret, must of course, be a "secret". 2. Cannot be readily ascertainable to someone skilled in the art. 3. Reasonable safegards must have been taken to protect it's secrecy. 4. Must have indendent economic value. Technically, based on the premise of negative knowledge, someone could work for company A trying to build a software product, and fail at each attempt, thereby, accumulating negative knowledge. This person could then quit and go to work for Company B, build the same product, this time completing it, using previous negative knowledge gained from Company A. If Company A, had an agreement respecting trade secrets, under inevitability, Company A could claim the Company B's product was based on their IP if the employee did it within 18 months of departing Company A. This is why I think inevitability is a ridculous doctrine. It makes claim to the work experinece of employees as IP. In theory, an employee could not obtain the injunction because he would have no standing to bring a cause of action, but the copyright holder would have standing and could if he could show that the employee used negative knowledge and that he did so within a certain period of time. It's even more complicated, trade secret law makes claims that common software components arranged in new ways would qualify as a trade secret. This could also mean that any new software this person wrote would necessarily be intertwined with GPL code and trade secrets of the employer. In such a case, a Judge would "balance the equities", and would have to make a call, like telling the company to remove the GPL sections, and/or requireing the portions of the code be open sourced. He could also go the other way, and rule some sections are not covered under inevitablity. It would be a very complex case, BTW (trade secrets cases always are). :-) 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/
NWFS mkfs.nwfs and fsck.nwfs tools issues -- need input
Alan, I guess since my brain is 40+ years old and dying, I will keep getting slower... and slower . integrating this into a release is about 4 times the work I had thought (GNU partspec -- what is mess!!!). 2.4 seems to have stopped changing and is very stable, and Linus appears to have stopped playing in it so I am motivated to add this now for a 2.4 release since 2.4 is so stable. I have had to do some things to get around the inode mapping problem to work with Linux that really makes native NetWare stand on it's head. What I've done to support true Linux hard links and static inode numbers is to simply backlink changed records within a 4K directory block to the new parent. Oddly, there were some cases that would make Native NetWare break when it saw this, but I have tested this change now for about two months with every rev from 3.x through 5.x NetWare, and have identified the cases where I need to recreate directory entries and move the file entries to a new block vs. just backlink them. As it turns out, I can safely backlink any regular files, thereby preserving the directory relative number in the dir file I use as a static inode number. This was an extremely complex problem that required an enormous testing effort, since NetWare always assumes all entries within a single 4K block are owned by the same parent. There were cases in the NFS server where this was allowed to happen to support NFS on NetWare, and it is this behavior that I am exploiting. As it turns our the only place I have to move directory entries is when I move deleted files to the DELETED.SAV directory, which Linux is totally ignorant of in any event -- they just show up as new files, which is OK (it's not an implied mv (rename) operation since deleted files from a linux perspective are expected to disappear from a volume). I also eliminated all the in memory name hases except for the the root DOS namespace and reduced memory usage by a factor of 10, and implemented the extended directory for 255 > character names. I have modified anaconda to install NWFS partitions and am working on Unix-like fsck.nwfs and mkfs.nwfs tools. I've had to do some things the linux way to get this working correctly. Some issue, questions, need guidance stuff for the merge of this code. A). NWFS doesn't use the "rule of 1" (1 partition - 1 file system) and can stripe volumes, mirror volumes, etc. B). In order to make install and most of the linux tools work properly, I have to provide this "rule of 1" behavior. So there is a limitation for installing and using multi-segmented NWFS volumes on Linux for root filesystems, what I have done is set the default behavior to this: mkfs.nwfs /dev/hda SYS just like the linux tools behave with ext2, however, this will always limit a root volume to one NetWare volume segment on one Linux partition, and it should probably always by named "SYS" if it's the root, so MARS will be able to provide default NetWare behavior. This tool also allows NetWare volumes to be created in these funky Linux extended partitions with a "rule of 1" behavior. If people want to configure stripping, mirroring, multi-segmented volumes, or if they want to dynamically add segments to live root NWFS volumes, The NWCONFIG tools let them do this after the fact or install. If existing NetWare volumes exist on the server, I have modified the anaconda installer to look for SYS, and use it as the root volume for the linux install. I made fsck.nwfs a little smarter, and it can repair stripped and mirrored volumes as well as these "linux clone" netware volumes on extended partitions. questions: 1. Do I tar.gz the nwfs tools source base, and post as nwfs-utils.tar.gz separate from the patch, and will these be posted with the ext2 tools? Are you ready if I post NWFS to merge 2.2.18 patches? 2. Will a 2.4 patch for NWFS be accepted this close to release. It only adds some config options and it'w own atomic code. High and low water marks to adjust LRU memory usage key off variables in the OS, and I have not needed to put in any patches to standard code -- I even got around the 512 buffer head thing. 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/
