Re: [PATCH] Remove silly beep macro from pgtable.h
On Tue, 15 May 2001, Jonathan Lundell wrote:
> At 7:36 PM +0200 2001-05-15, Mike Galbraith wrote:
> >On Tue, 15 May 2001, Jeff Golds wrote:
> >
> >> Hi folks,
> >>
> >> Found this bit of unused code in the i386 and sh architectures.
> >>As it's not being used, let's get rid of it. Also, pgtable.h seems
> >>to be an odd place for this.
> >
> >I'd leave it.. folks with early boot troubles might find it useful.
> >
> > -Mike
>
> Consider small rant about literal IO references to magic locations
> hereby ranted. Especially in header files completely unrelated to the
> IO function in question.
>
> -#define __beep() asm("movb $0x3,%al; outb %al,$0x61")
>
> Let's please not assume that every i386 implementation has a full set
> of legacy PC IO hardware.
Is there a generic form of hello() that could be tucked away somewhere?
-Mike
-
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/
IRQ usage for PCI devices, Kernel 2.4.4
Hi, sometimes the following messages appear in /var/log/messages: May 13 14:24:41 sunny kernel: PCI: Found IRQ 10 for device 00:0e.0 May 13 14:24:41 sunny kernel: PCI: The same IRQ used for device 00:0a.0 "0e" is my PCI sound card, and "0a" is my PCI ethernet card. The messages apppear in the following environment: I send from another linux machine (per ssh) a command wich plays some sound on my sound card, therefore the eth0 event and the sound event occur at almost the same time. Question: Can I ignore these messages, or is there any buggy behaviour? Regards Joachim Backes -- Joachim Backes <[EMAIL PROTECTED]> | Univ. of Kaiserslautern Computer Center, High Performance Computing | Phone: +49-631-205-2438 D-67653 Kaiserslautern, PO Box 3049, Germany | Fax: +49-631-205-3056 -+ WWW: http://hlrwm.rhrk.uni-kl.de/home/staff/backes.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 kernel freeze for unknown reason
On Tuesday 15 May 2001 02:13, Jacky Liu wrote: > Hi everyone, > > Mark, I got your point about the dma/udma stuffs. My hdparm setting is > UDMA w/ MultiSector 16.. > > I had recompiled my kernel and disabled the FB option but my linux box > still hanged (another completely freeze) yesterday... Oh well.. > > I have been tracking this thread for a few days and it seem the source of > this problem is related to swap space. Vincent, would you mind to send me > the patch for swap space problem if Alan had sent it to you? So I can > test it on my machine and report the result later. > I havn't received the patch but, on Byron Stanoszek's suggestion, I have compiled 2.4.4 with gcc-2.95.3 to run on it a few days to see if it is any better. So far, it appears at least as stable as with egcs-1.1.2 and most of the swap was freed up this morning for the first time since 2.4.0. However, it is pretty full tonight. I should know tomorrow if it really made a difference. This is usually the state in which I find it locked up the next morning. It has been up a little over 2 days now. Byron actually suggested I use the ac7 patch but I first wanted to see if the compiler had anything to do with it without changing anything else. > Mark, please suggest a setting for the hdparm so I can test it on my > machine. Thanks alot for your time. > > Best Regards, > Jacky Liu > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: LANANA: To Pending Device Number Registrants
Miles Lane <[EMAIL PROTECTED]> wrote on 15/5/01 17:41: >Does your approach solve >the problem of USB devices, >like mice, that >don't have device ID's of any >sort, where topology is the >only way to >distinguish them? yes, that's what the location part is for. Bye... - 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: kernel2.2.x to kernel2.4.x
> From: jalaja devi [mailto:[EMAIL PROTECTED]] > > I tried porting a network driver from kernel2.2.x to > 2.4. When i tried loading the driver, it shows the > unresolved symbols for > copy_to_user_ret > outs > __bad_udelay > > Could anyone please tell me the corresponding fxns in 2.4. You need to "unroll" copy_to_user_ret(). There is no corresponding macro. Just test the condition and return -EFAULT (?; not looking at the source code) if it's invalid. Don't know about "outs". __bad_udelay means that some module used a too-large-parameter-value to udelay(). Linker should be telling you which module. ~Randy - 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: Not a typewriter
On Thu, 10 May 2001 [EMAIL PROTECTED] wrote: > I disagree. "Not a typewriter" is part of Unix tradition, and ought > to be retained as a historical reference. It's also an opportunity > for "the uninitiated" to learn a little more and move a little closer > to becoming "the initiated." We should maintain the Unix tradition. I would feel very unhappy if I happen to use a system call "create" to make a file. Anuradha -- http://www.bee.lk/people/anuradha/;>home page - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2 - Locked keyboard
On Thu, 10 May 2001, Jorge Boncompte [DTI2] wrote: > After the reboot, the keyboard was working 5 minutes and then it > locked. The console was working. I rebooted the machine again and has > been working for 2 days, that the keyboard gets locked again. Just to make sure... Did you check scoll lock? :) Anuradha -- http://www.bee.lk/people/anuradha/;>home page - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][CFT] (updated) ext2 directories in pagecache
Sorry, I couldn't think of any good flames that haven't already been posted so I thought I'd be boring and post some code. ;-) On Monday 14 May 2001 23:50, Daniel Phillips wrote: > On Monday 14 May 2001 20:33, Andreas Dilger wrote: > > Daniel, you write: > > > Now, if the check routine tells us how much good data it found we > > > could use that to set a limit for the dirent scan, thus keeping > > > the same robustness as the old code but without having all the > > > checks in the inner loop. Or. We could have separate loops for > > > good blocks and bad blocks, it's just a very small amount of > > > code. > > > > Yes, I was thinking about both of those as well. I think the > > latter would be easiest, because we only need to keep a single > > error bit per buffer. > > Today's patch has the first part of that fix: > > http://nl.linux.org/~phillips/htree/dx.pcache-2.4.4-6 And today's has the second part of that mechanism. This is the strategy: - When a directory block is first called for via ext2_bread, !create, and is !uptodate, ext2_check_dirents is called to go through and sniff anally for anything that might not be right. This check only happens once per block's cache lifetime. - If check_dirents returns failure, ext2_bread sets the PG_error bit in the buffer's page flags. - Just before we do the lowlevel scan of a directory leaf we check the page error bit, and if it's set call check_dirents, this time asking it to tell us how much of the block is good. That value is used to set the limit for the lowlevel scan. This recovers the old behaviour where the user continues to see all the directory entries up to the first bad one. Is it really important to do this? Now at least we can decide whether that's the behaviour we want instead of worrying about how it can be implemented efficiently. This high level of paranoia costs practically nothing; there are no extra checks to slow down the inner loop. Thanks to Al Viro for the inspiration. I only implemented this check in one place, line 807 in ext2_find_entry on the nonindexed path. If the approach looks ok I'll go and add it in the other places. Extending the idea to do an equally paranoid check on the directory index structure will add a little messiness because check_dirents can't tell that a given block is actually an index block, it has to be told. I'll just let this sit and age a little before I uglify the code in that way. On another front, I've changed to a new COMPAT flag so that Andreas Gruenbacher's ACL users can stick with the flag Andreas is already using. I haven't heard a definitive ruling from Ted on this yet, but I gather this is the one I'm now supposed to use: #define EXT2_FEATURE_COMPAT_DIR_INDEX 0x0020 The current patch uses this, pending Ted's approval. I'll repeat my warning that any partition with an indexed directory will need to be mke2fsed, until the patch gets to official alpha. The patch is at: http://nl.linux.org/~phillips/htree/dx.pcache-2.4.4-7 This is hardly tested at all, it's for comment. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.20pre2aa1
On Tue, 15 May 2001, Andrea Arcangeli wrote: > o fixed race in wake-one LIFO in accept(2). Apache must be compiled with > -DSINGLE_LISTEN_UNSERIALIZED_ACCEPT to take advantage of that. > > 00_wake-one-4 > > Backport 2.4 waitqueues and in turn fixes an hanging condition in accept(2). > > (me) apache since 1.3.15 has defined SINGLE_LISTEN_UNSERIALIZED_ACCEPT ... 'cause that's what you guys asked me to do :) does this mean there are known hangs on linux 2.2.x without your fix? -dean - 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: LANANA: To Pending Device Number Registrants
On Tuesday May 15, [EMAIL PROTECTED] wrote:
>
> On Tue, 15 May 2001, Neil Brown wrote:
> >
> > Ofcourse setting the "queue" function that __blk_get_queue call to do
> > a lookup of the minor and choose an appropriate queue for the "real"
> > device wont work as you need to munge bh->b_rdev too.
>
> What I would do is:
> - remove b_rdev completely. No driver is actually interested in what the
>device number is, the only thing they want to use it for is to look up
>which device index we have (and for doing the partition handling, but
>as discussed in a completely independent discussion a few months ago,
>we should handle that as a lvm remapping thing, NOT at the driver
>level!)
> - replace is with b_index
Wouldn't
struct block_device *b_bdev
be a better choice? (though you would need to fiddle with reference
counts then, so maybe not, I'm not sure).
>
> > You would still nee to make sure the blk_size[], blksize_size[],
> > hardsect_size[], max_readahead[], max_sectors[] all got handled
> > properly.
>
> Actually, I htink Jens did most of these, and moved them into a device
> array.
>
Will this go into 2.4.X anytime soon? or is it 2.5 material?
> > Does the minor number for this "disk" layer have N bits for partition
> > number and 8-N bits (later to be 20-N bits or similar) for device
> > number?
>
> I'd go with N=8, and only use this for the "new" cases, We've seen that
> N=4 is too small (SCSI), and N=6 (IDE) is already too cramped with a 8-bit
> minor number.
I was assuming that this "disk" device was something that we could do
now, but if N==8, then we need more minor bits before it can be used
effectively, and that means lots of user-space changes doesn't it? So
it won't be in 2.4.
>
> BUT! Note that when you do the partition handling in get_queue too (and
> thus index is an index to the _device_ and has nothing to do with
> partitions), you can trivially allow different majors to have different
> numbers of partition bits, because the driver no longer cares. This is
> required so that the get_queue remapping can easily handle the legacy
> IDE/SCSI numbers anyway, so it's easyish to just have both at the same
> time - you could have N=4 for a "disk major for old users that need the
> 16-bit device numbers and a single major", with N=8 for the "new style
> major" which doesn't fit in 8 bits.
Uhm. If I understand you correctly, you are saying that a single
major (the "disk" major) could have different partition sub-divisions
for different minor ranges. e.g:
minor 0-15 is partitions of first scsi drive
minor 16-31 is partitions of second scsi drive
minor 64-128 is partitions of first IDE drive
Is that what you mean? I wouldn't want to have to maintain /dev/...
>
> > Finally, how do I say that I want the root filesystem to be on a
> > particular "mdp" device+partition. I cannot assume that my device
> > will be the first to register with the "disk" layer, so I cannot be
> > sure that "root=/dev/diska1" will work.
>
> You have never been able to really assume that. Disks move around.
>
> A lot of people seem to think that controller type or location on the PCI
> bus should somehow have some "meaning", and that it guarantees that the
> disks don't move in the namespace. That's crap. You can do that in user
> space ("what controller are you on?") if you really really care.
This is a topic that seems to be generating alot of discussion in these
threads.
Clearly each object (drive, partitions, filesystem, pointer, mouse,
framebuffer...) can potentially have several different names, each of
which may be valid in it's own context. I think the kernel should
export all names equally without prejudice.
NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.2.19 + VIA chipset + strange behaviour
Bug in include/linux/module.h. Patch against 2.2.19. This does not
explain your oops, the ksymoops message is a separate bug.
Index: 19.1/include/linux/module.h
--- 19.1/include/linux/module.h Tue, 12 Sep 2000 13:37:17 +1100 kaos
(linux-2.2/F/51_module.h 1.1.7.2 644)
+++ 19.1(w)/include/linux/module.h Wed, 16 May 2001 12:52:53 +1000 kaos
+(linux-2.2/F/51_module.h 1.1.7.2 644)
@@ -228,9 +228,9 @@ const char __module_using_checksums[] __
#define MOD_DEC_USE_COUNT do { } while (0)
#define MOD_IN_USE 1
-extern struct module *module_list;
-
#endif /* !__GENKSYMS__ */
+
+extern struct module *module_list;
#endif /* MODULE */
-
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: rwsem, gcc3 again
mirabilos wrote: > > Hi, > I have got that patch with "movl %2,%%edx" and removing the tmp > and still cannot compile with the same error message I posted yesterday. > The problem seems to be that, with or without "inline", it seems to > put a reference into main.o of arch/i386/boot/compressed. > So I cannot test -ac9 :( > > If anyone could find a (final or at least until gcc is fixed temporarily) > solution please please could either post or mail me? > Please no Cc: as I am on the list. > > -mirabilos > -- Hi, Petr Vandrovic's patch works for me. $ cat /proc/version Linux version 2.4.5-pre1 (tleete@mercury) (gcc version 3.0 20010423 (prerelease)) #6 Tue May 15 07:13:10 EDT 2001 You don't mention the constraint changes, did you apply them too? I posted a simpler patch which miscompiled on gcc3 and 2.95.3. Still trying to understand why, it was Obviously Correct. It was also the cause of my boot hangs. Cheers, Tom -- The Daemons lurk and are dumb. -- Emerson - 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/
DVD_AUTH ioctl fails with aic7xxx / 2.4.4
I've set up a Pioneer 305S scsi dvd-rom on an old adaptec card using the
stock aic7xxx driver included with the 2.4.4 kernel (not the old_aic7xxx
one). Everything works well, except when trying to access an encrypted
file on a DVD. This ioctl from libcss fails:
static int _get_title_key(int fd, int agid, int lba, char *key, char *key_title)
{
dvd_authinfo ai;
int i;
ai.type = DVD_LU_SEND_TITLE_KEY;
ai.lstk.agid = agid;
ai.lstk.lba = lba;
if (ioctl (fd, DVD_AUTH, )) {
perror ("GetTitleKey failed");
return -1;
}
All I see from the kernel is:
sr1: CDROM (ioctl) reports ILLEGAL REQUEST.
This happens with any DVD. Can someone tell me what the problem is? I
seem to be using the same libcss that everyone else uses with no
problem, and everything is properly configured, AFAIK.
thanks,
Jason
-
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: LANANA: To Pending Device Number Registrants
Jonathan Lundell wrote: > > ... > I *like* eth0..n (I'd like net0..n better). And I *can't* ask what > eth0 and eth1 are, by the way, but I should be able to (Jeff Garzik > has proposed an extension to ethtool to help out this lack, but it's > not in Linux today, and needs concrete implementation anyway). > > But that's not my point. I'm *not* proposing that we exchange eth0 > for geographic names. I'm suggesting, though, that the location of > the device is *not* meaningless, because it's the physically-located > RJ45 socket (or whatever) that I have to connect a particular cable > to. Sure, no big deal for systems with a single connection, but it > becomes a real pain when you've got a dozen, which is a reasonable > number for some network-infrastructure functions (eg firewalls). > > When I ifconfig one of a collection of interfaces, I'm very much > talking about the specific physical interface connected via a > specific physical cable to a specific physical switch port. > Yes, it can be a security trap as well - physically move a card and your firewall rules end up being applied to the wrong connection. The 2.4 kernel allows you to rename an interface. So you can build a little database of (MAC address/name) pairs. Apply this after booting and before bringing up the interfaces and everything has the name you wanted, based on MAC address. Andi Kleen has an app which does this: ftp://ftp.firstfloor.org/pub/ak/smallsrc/nameif.c but apparently some additional kernel work is needed to make this work 100% correctly. I do not know what the specific problem is. - - 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: LANANA: To Pending Device Number Registrants
At 9:34 PM -0400 2001-05-15, Nicolas Pitre wrote:
>On Wed, 16 May 2001, Daniel Phillips wrote:
>
>> On Tuesday 15 May 2001 23:20, Nicolas Pitre wrote:
>> > Personally, I'd really like to see /dev/ttyS0 be the first detected
>> > serial port on a system, /dev/ttyS1 the second, etc.
>>
>> There are well-defined rules for the first four on PC's. The ttySx
>> better match the labels the OEM put on the box.
>
>Then just make them be detected first.
Well, they traditionally start with 1, not 0, too. Or have cute
little icons and no text. Or aren't labelled at all. I'm using one
fairly well-known dual-port PCI serial board that silently
interchanged the two ports on a rev change, with no labelling change
at all ('cause there was no label!). Make your ttySx match *that*!
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.2.19 + VIA chipset + strange behaviour
> On Tue, 15 May 2001 18:04:35 +0930 (CST), > Jonathan Woithe <[EMAIL PROTECTED]> wrote: > >ksymoops 2.4.1 on i686 2.2.19. Options used > >Warning (compare_maps): ksyms_base symbol module_list_R__ver_module_list not found >in System.map. Ignoring ksyms_base entry > > module_list was added to the export list in 2.2.17 so the message above > implies that you are using kernel build information from 2.2.17 in your > 2.2.19 build. I suggest you follow http://www.tux.org/lkml/#s8-8 and > see if your problems recur after a completely clean kernel build. This is curious because the compilation was done from a completely fresh 2.2.19 tree (ie: not patched, no old .configs used). In any case, I have just carried out the following as per the URL above: mv .config .. make mrproper mv ../.config . make oldconfig make dep clean bzImage modules # install, boot After going through these steps and rebooting, ksymoops still complains about the missing symbol, and checking System.map confirms that module_list_R__ver_module_list is indeed not present: auster:~>ksymoops ksymoops 2.4.1 on i686 2.2.19. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.2.19/ (default) -m /usr/src/linux/System.map (default) : Warning (compare_maps): ksyms_base symbol module_list_R__ver_module_list not found in System.map. Ignoring ksyms_base entry /usr/src/linux is a symlink to the 2.2.19 tree. The mystery of this ksymoops message remains. Thanks and regards jonathan -- * Jonathan Woithe[EMAIL PROTECTED]* *http://www.physics.adelaide.edu.au/~jwoithe* ***---*** ** "Time is an illusion; lunchtime doubly so" ** * "...you wouldn't recognize a subtle plan if it painted itself purple * * and danced naked on a harpsicord singing 'subtle plans are here again'" * - 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: LANANA: To Pending Device Number Registrants
On Wed, 16 May 2001, Daniel Phillips wrote: > On Tuesday 15 May 2001 23:20, Nicolas Pitre wrote: > > Personally, I'd really like to see /dev/ttyS0 be the first detected > > serial port on a system, /dev/ttyS1 the second, etc. > > There are well-defined rules for the first four on PC's. The ttySx > better match the labels the OEM put on the box. Then just make them be detected first. Nicolas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.4.5-pre2 mm/filemap.c
Hi Linus,
here are a filemap.c fix and a slight addition, with the first
fix changed as discussed by email.
1) __find_page_nolock should only set the referenced bit
on an active page, otherwise a number of subsequent
reads from the same page within one page scan interval
can SEVERELY mess up page aging to the disadvantage of
the other pages in the system ...
just setting the referenced bit on the page makes the
aging a lot fairer
2) in drop_behind() we first increase the page age and
will then proceed to deactivate the page again; better
have a simpler help function for this ... note that this
help function could also be used for eg. ->writepage()
write clustering code
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/ http://distro.conectiva.com/
Send all your spam to [EMAIL PROTECTED] (spam digging piggy)
--- linux-2.4.5-pre2/mm/filemap.c.orig Tue May 15 22:00:15 2001
+++ linux-2.4.5-pre2/mm/filemap.c Tue May 15 22:08:04 2001
@@ -284,6 +284,34 @@
spin_unlock(_lock);
}
+/*
+ * This function is pretty much like __find_page_nolock(), but it only
+ * requires 2 arguments and doesn't mark the page as touched, making it
+ * ideal for ->writepage() clustering and other places where you don't
+ * want to mark the page referenced.
+ *
+ * The caller needs to hold the pagecache_lock.
+ */
+struct page * __find_page_simple(struct address_space *mapping, unsigned long index)
+{
+ struct page * page = *page_hash(mapping, index);
+ goto inside;
+
+ for (;;) {
+ page = page->next_hash;
+inside:
+ if (!page)
+ goto not_found;
+ if (page->mapping != mapping)
+ continue;
+ if (page->index == index)
+ break;
+ }
+
+not_found:
+ return page;
+}
+
static inline struct page * __find_page_nolock(struct address_space *mapping,
unsigned long offset, struct page *page)
{
goto inside;
@@ -298,14 +326,9 @@
if (page->index == offset)
break;
}
- /*
-* Touching the page may move it to the active list.
-* If we end up with too few inactive pages, we wake
-* up kswapd.
-*/
- age_page_up(page);
- if (inactive_shortage() > inactive_target / 2 && free_shortage())
- wakeup_kswapd();
+ /* Mark the page referenced, kswapd will find it later. */
+ SetPageReferenced(page);
+
not_found:
return page;
}
@@ -762,7 +785,6 @@
{
struct inode *inode = file->f_dentry->d_inode;
struct address_space *mapping = inode->i_mapping;
- struct page **hash;
struct page *page;
unsigned long start;
@@ -783,8 +805,7 @@
*/
spin_lock(_lock);
while (--index >= start) {
- hash = page_hash(mapping, index);
- page = __find_page_nolock(mapping, index, *hash);
+ page = __find_page_simple(mapping, index);
if (!page)
break;
deactivate_page(page);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.4.5-pre2 mm/vmscan.c
Hi Linus,
the patch is regenerated against 2.4.5-pre2 and changed as
discussed with marcelo (the "+ inactive_target / 3" is gone).
Full description:
1) fix swap_amount() to never return a swap count larger than
the process' RSS and swap_out() to return immediately when
swapping out a process with 0 RSS
2) the counter in swap_out() is corrected with a factor of
1<= change in __alloc_pages(), we can drop the silly
+1 thing from free_shortage()
7) the "+ inactive_shortage / 3" thing in free_shortage() is gone
8) updated the comments to refill_inactive()
9) in refill_inactive(), make it possible for kswapd to fix even
big inactive shortages with just one scan; this should avoid
spurious kswapd wakeups, context switches and apps blocking
while trying to free pages themselves ... note how not being
able to deactivate enough pages interferes with the ability to
free pages and the kswapd sleep condition
10) change the balancing loop in refill_inactive() so both
refill_inactive_scan() and swap_out() are called in the same way
and can be balanced
11) in do_try_to_free_pages() only call page_launder() for situations
page_launder actually tries to solve ... calling it in a situation
which page_launder doesn't solve will only waste CPU
12) move the background scanning into the once-a-second block, this
probably doesn't have any performance influence at all but I like
it better this way ;)
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/ http://distro.conectiva.com/
Send all your spam to [EMAIL PROTECTED] (spam digging piggy)
--- linux-2.4.5-pre2/mm/vmscan.c.orig Tue May 15 22:00:15 2001
+++ linux-2.4.5-pre2/mm/vmscan.cTue May 15 22:19:55 2001
@@ -24,6 +24,8 @@
#include
+#define MAX(a,b) ((a) > (b) ? (a) : (b))
+
/*
* The swap-out function returns 1 if it successfully
* scanned all the pages it was asked to (`count').
@@ -228,6 +230,8 @@
unsigned long address;
struct vm_area_struct* vma;
+ if (!count)
+ return 1;
/*
* Go through process' page directory.
*/
@@ -271,7 +275,12 @@
static inline int swap_amount(struct mm_struct *mm)
{
int nr = mm->rss >> SWAP_SHIFT;
- return nr < SWAP_MIN ? SWAP_MIN : nr;
+ if (nr < SWAP_MIN) {
+ nr = SWAP_MIN;
+ if (nr > mm->rss)
+ nr = mm->rss;
+ }
+ return nr;
}
static int swap_out(unsigned int priority, int gfp_mask)
@@ -285,7 +294,7 @@
retval = swap_out_mm(mm, swap_amount(mm));
/* Then, look at the other mm's */
- counter = mmlist_nr >> priority;
+ counter = (mmlist_nr << SWAP_SHIFT) >> priority;
do {
struct list_head *p;
@@ -350,7 +359,7 @@
}
/* Page is or was in use? Move it to the active list. */
- if (PageTestandClearReferenced(page) || page->age > 0 ||
+ if (PageReferenced(page) || page->age > 0 ||
(!page->buffers && page_count(page) > 1)) {
del_page_from_inactive_clean_list(page);
add_page_to_active_list(page);
@@ -453,7 +462,7 @@
}
/* Page is or was in use? Move it to the active list. */
- if (PageTestandClearReferenced(page) || page->age > 0 ||
+ if (PageReferenced(page) || page->age > 0 ||
(!page->buffers && page_count(page) > 1) ||
page_ramdisk(page)) {
del_page_from_inactive_dirty_list(page);
@@ -631,21 +640,42 @@
/**
* refill_inactive_scan - scan the active list and find pages to deactivate
* @priority: the priority at which to scan
- * @oneshot: exit after deactivating one page
+ * @target: number of pages to deactivate, zero for background aging
*
* This function will scan a portion of the active list to find
* unused pages, those pages will then be moved to the inactive list.
*/
-int refill_inactive_scan(unsigned int priority, int oneshot)
+int refill_inactive_scan(unsigned int priority, int target)
{
struct list_head * page_lru;
struct page * page;
- int maxscan, page_active = 0;
- int ret = 0;
+ int maxscan = nr_active_pages >> priority;
+ int page_active = 0;
+ int nr_deactivated = 0;
+
+ /*
+* When we are background aging, we try to increase the page aging
+* information in the system. When we have too many inactive pages
+* we don't do background aging since having all pages on the
+* inactive list decreases aging information.
+*
+* Since not all active pages have to be on the active list, we round
+* nr_active_pages up to num_physpages/2, if needed.
+*/
+
Re: Getting FS access events
Anton Altaparmakov wrote: > > And how are you thinking of this working "without introducing new > interfaces" if the caches are indeed incoherent? Please correct me if I > understand wrong, but when two caches are incoherent, I thought it means > that the above _would_ screw up unless protected by exclusive write locking > as I suggested in my previous post with the side effect that you can't > write the boot block without unmounting the filesystem or modifying some > interface somewhere. > Not if direct device acess and the superblock exist in the same mapping space, OR an explicit interface to write the boot block is created. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ymfpci.h add PCIR_DSXPWRCTRL1 && PCIR_DSXPWRCTRL2
Woopsthis is for 2.4.5-pre2 -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ymfpci.h add PCIR_DSXPWRCTRL1 && PCIR_DSXPWRCTRL2
This part of the whole ymfpci change is missing -- = 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] = --- linux/drivers/sound/ymfpci.h.orig Tue May 15 21:15:54 2001 +++ linux/drivers/sound/ymfpci.hTue May 15 21:17:30 2001 @@ -135,6 +135,8 @@ #define PCIR_LEGCTRL 0x40 #define PCIR_ELEGCTRL 0x42 #define PCIR_DSXGCTRL 0x48 +#define PCIR_DSXPWRCTRL1 0x4a +#define PCIR_DSXPWRCTRL2 0x4e #define PCIR_OPLADR0x60 #define PCIR_SBADR 0x62 #define PCIR_MPUADR0x64
Re: Getting FS access events
At 23:35 15/05/2001, H. Peter Anvin wrote: >"Albert D. Cahalan" wrote: > > H. Peter Anvin writes: > > > This would leave no way (without introducing new interfaces) to write, > > > for example, the boot block on an ext2 filesystem. Note that the > > > bootblock (defined as the first 1024 bytes) is not actually used by > > > the filesystem, although depending on the block size it may share a > > > block with the superblock (if blocksize > 1024). > > > > The lack of coherency would screw this up anyway, doesn't it? > > You have a block device, soon to be in the page cache, and > > a superblock, also soon to be in the page cache. LILO writes to > > the block device, while the ext2 driver updates the superblock. > > Whatever gets written out last wins, and the other is lost. > >Albert, I *did* say "this better work or we have a problem." And how are you thinking of this working "without introducing new interfaces" if the caches are indeed incoherent? Please correct me if I understand wrong, but when two caches are incoherent, I thought it means that the above _would_ screw up unless protected by exclusive write locking as I suggested in my previous post with the side effect that you can't write the boot block without unmounting the filesystem or modifying some interface somewhere. As not all filesystems are like ext2, perhaps it would be better to fix ext2 and not the cache coherency? If ext2 is claiming ownership of a device, then it should do so in its entirety IMHO. You could always extend ext2 to use the NTFS approach where the bootsector is nothing more than a file which happens to exist on sector(s) zero (and following) of the device... (just a thought) Best regards, Anton -- Anton Altaparmakov (replace at with @) Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/ - 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: LANANA: To Pending Device Number Registrants
Daniel Phillips wrote: > > Sounds like "treat it like a file and it acts like a file, treat it > like a directory and it acts like a directory". > The original plan was that you only could indirect through it; not chdir() for example. One could do the whole enchilada, but then one would have to expect that open() could have very different effects with and without O_DIRECTORY (and open() on directories without O_DIRECTORY should be outlawed with prejudice.) -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Tuesday 15 May 2001 23:20, Nicolas Pitre wrote: > Personally, I'd really like to see /dev/ttyS0 be the first detected > serial port on a system, /dev/ttyS1 the second, etc. There are well-defined rules for the first four on PC's. The ttySx better match the labels the OEM put on the box. -- Daniel - 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: LANANA: To Pending Device Number Registrants
On Tuesday 15 May 2001 22:51, Linus Torvalds wrote: > On Tue, 15 May 2001, Alexander Viro wrote: > > If you want them all to inherit it - inherit from mountpoint. > > ..which is exactly what the device node ends up being. The implicit > mount-point. > > And which point, btw, it is completely indistinguishable to user > space whether the thing is implemented as a full filesystem, or > whether it's just that the device node exports a simple "lookup()" > that it passes down to the device driver. So this is also the point > where it becomes nothing but an implementation issue, and as such > it's much less contentious. > > Done right, they'll be automatic mount-points Sounds like "treat it like a file and it acts like a file, treat it like a directory and it acts like a directory". -- Daniel - 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: LANANA: To Pending Device Number Registrants
On Tuesday 15 May 2001 17:34, Linus Torvalds wrote: > On Tue, 15 May 2001, Neil Brown wrote: > > Ofcourse setting the "queue" function that __blk_get_queue call to > > do a lookup of the minor and choose an appropriate queue for the > > "real" device wont work as you need to munge bh->b_rdev too. > > What I would do is: > - remove b_rdev completely. :-) And b_rsector too? > [...] > - replace is with b_index > > Then, the "get_queue" functions basically end up doing the mapping of > > b_dev -> To clarify, will be b_index be in the buffer_head or not? -- Daniel - 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: LANANA: To Pending Device Number Registrants
At 1:18 PM -0700 2001-05-15, Linus Torvalds wrote: > > 1 (network domain). I have two network interfaces that I connect to >> two different network segments, eth0 & eth1; > >So? > >Informational. You can always ask what "eth0" and "eth1" are. > >There's another side to this: repeatability. A setup should be >_repeatable_. > >This is what we have now. Network devices are called "eth0..N", and nobody >is complaining about the fact that the numbering is basically random. It >is _repeatable_ as long as you don't change your hardware setup, and the >numbering has effectively _nothing_ to do with "location". > >You don't say "oh, I have my network card in PCI bus #2, slot #3, >subfunction #1, so I should do 'ifconfig netp2s3f1'". Right? > >The location of the device is _meaningless_. I *like* eth0..n (I'd like net0..n better). And I *can't* ask what eth0 and eth1 are, by the way, but I should be able to (Jeff Garzik has proposed an extension to ethtool to help out this lack, but it's not in Linux today, and needs concrete implementation anyway). But that's not my point. I'm *not* proposing that we exchange eth0 for geographic names. I'm suggesting, though, that the location of the device is *not* meaningless, because it's the physically-located RJ45 socket (or whatever) that I have to connect a particular cable to. Sure, no big deal for systems with a single connection, but it becomes a real pain when you've got a dozen, which is a reasonable number for some network-infrastructure functions (eg firewalls). When I ifconfig one of a collection of interfaces, I'm very much talking about the specific physical interface connected via a specific physical cable to a specific physical switch port. Bob Glamm is on the right track with At 5:35 PM -0500 2001-05-15, Bob Glamm wrote: > # start up networking > for i in eth0 eth1 eth2; do > identify device $i > get configuration/config procedure for device $i identity > configure $i > done ...it's just that right now the connection between eth* and its physical identity isn't made. -- /Jonathan Lundell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/sch0 interface
On Tue, May 15, 2001 at 11:44:23PM +, Thorsten Kranzkowski wrote: > On Tue, May 15, 2001 at 03:08:01PM -0600, Jeff V. Merkey wrote: > > > > > > Is anyone actuaslly using the /dev/sch0 interface for SCSI tape changers > > in Linux? I noticed that the device definitions are present, but I do not > > see any driver shipped in the standard base that actually uses it. > > http://www.in-berlin.de/User/kraxel/linux.html > > works very well here (needs a minor #include to compile correctly, though) > > I actually wonder why this isn't in the mainline kernel. > > > > > Thanks > > > > Jeff > > > > Thorsten Thanks. Jeff > > -- > | Thorsten KranzkowskiInternet: [EMAIL PROTECTED]| > | Mobile: ++49 170 1876134 Snail: Niemannsweg 30, 49201 Dissen, Germany | > | Ampr: dl8bcu@db0lj.#rpl.deu.eu, [EMAIL PROTECTED] [44.130.8.19] | - 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: LANANA: To Pending Device Number Registrants
On 16 May 2001 01:56:23 +0200, Tim Jansen wrote: > On Wednesday 16 May 2001 01:16, David Brownell wrote: > >Only if it's augmented by additional device IDs, such as the > >"what 's the physical connection for this interface" sort of > >primitive that's been mentioned. > >[...] > > I suppose that for network interface names, some convention for > > interface ioctls would suffice to solve that "identify" step. PCI > > devices would return the slot_name, USB devices need something > > like a patch I posted to linux-usb-devel a few months back. > > At this point of the discussion I would like to point to the Device Registry > patch (http://www.tjansen.de/devreg) that already solves these problems and > offers stable device ids for the identification of devices and finding their > /dev nodes. Does your approach solve the problem of USB devices, like mice, that don't have device ID's of any sort, where topology is the only way to distinguish them? IIRC, the USB development team was planning to use topology to provide a limited ability to associate a mouse on a given port with a display, when XFree86 supports per-Xinerama-display input device associations. They new VT console work would benefit from this, too. Miles - 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/
kernel2.2.x to kernel2.4.x
I tried porting a network driver from kernel2.2.x to 2.4. When i tried loading the driver, it shows the unresolved symbols for copy_to_user_ret outs __bad_udelay Could anyone please tell me the corresponding fxns in 2.4. Thanks in advance Jalaja __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
At 4:35 PM -0700 2001-05-15, David Brownell wrote: >[ Re why "physical" device IDs _should_ have a critical role in sysadmin ] > >> I would have to agree that "stable" is critical to not driving people >> crazy. In the case of AIX, once a device is enumerated, it will retain >> the same name across reboots. Enough information is kept about each >> device to determine if it has already been enumerated (i.e. same I/O >> port address for serial devices, MAC address for ethernet cards, etc), >> or if it is a new device and should get a new name. > >I caught those refs to how AIX does this ... sounds worth learning from. >Does it handle USB "port addresses" (which bus and hub)? Solaris has a scheme that addresses the issue at well. Device nodes live in /devices (/dev has soft links into /devices) and have system-global-geographic names. In Solaris talk, the 0-1-2 of eth0-1-2 i an instance. There's a file /etc/pathtoinst that records the connection of an device instance to its /devices geographical name. It does keep naming stable, but can be a PITA at times when you're reconfiguring a system and *want* to renumber things. (There are magic ways to do it, though). That's all Solaris 2.6; not sure about 2.8. -- /Jonathan Lundell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is printing broke on sparc ?
Hello Tim ,
On Tue, 17 Apr 2001, Mr. James W. Laferriere wrote:
> On Tue, 17 Apr 2001, Tim Waugh wrote:
> > On Mon, Apr 16, 2001 at 05:54:41PM -0700, Mr. James W. Laferriere wrote:
> > > # /etc/printcap
> > > # Please don't edit this file directly unless you know what you are doing!
> > > # Be warned that the control-panel printtool requires a very strict format!
> > > # Look at the printcap(5) man page for more info.
> > > # This file can be edited with the printtool in the control-panel.
> > > ##PRINTTOOL3## LOCAL POSTSCRIPT 300x300 letter {} PostScript Default {}
> > > lp:\
> > > :sd=/var/spool/lpd/lp:\
> > > :mx#0:\
> > > :sh:\
> > > :lp=/dev/lp0:\
> > > :if=/var/spool/lpd/lp/filter:
> > [...]
> > > /c#eodiecnyotai rhernili s to rpaemn
> > > s eehpo o-.ROLPR0 roif{\=sl:x
> > > /p:ao/lr
> > Please try adjusting the 'udelay (1)' lines in
> > drivers/parport/ieee1284_ops.c:parport_ieee1284_write_compat to be
> > larger delays (for example, try replacing the 1s with 2s, or 5s, and
> > see if that makes things better).
> I am going to look and see if there might be a ioctl for that
> function . Failing that I shall recompile the kernel with each
> of those values & test until successful or it seems futile .
Tries both 2's & 5's , Both did the leaving things out . Although
in a differant pattern with each . Am going to try 10's next just
for grins . Twyl , JimL
++
| James W. Laferriere | System Techniques | Give me VMS |
| NetworkEngineer | 25416 22nd So | Give me Linux |
| [EMAIL PROTECTED] | DesMoines WA 98198 | only on AXP |
++
-
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: LANANA: To Pending Device Number Registrants
> > I suppose that for network interface names, some convention for
> > interface ioctls would suffice to solve that "identify" step. PCI
> > devices would return the slot_name, USB devices need something
> > like a patch I posted to linux-usb-devel a few months back.
>
> This is crap.
Only the ioctl part, though I confess to trolling for a better proposal ... :)
> If you want to do it - do it right. Accessing /dev/eth//MAC
> is trivial. Wanking with ioctls is not. And populating such tree
> is as simple as it gets.
For links without a stable MAC, /.../net//{pci-slot,usb-path,...}
is more like it, but I think that class of solution should be fine.
Now ... what should be the roles of "regular" file ops, devfs, usbdevfs,
procfs, and "devreg" ? That's the part that doesn't seem simple yet.
I'd expect a few rounds of code/design changes.
- Dave
-
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: LANANA: To Pending Device Number Registrants
I believe thats why there are persistant superblocks on the RAID partitions. You can switch them around, and it still knows which drive holds which RAID partition... That's the only way booting off RAID works, and the only reason for the "RAID Autodetect" partition type... you can find those shuffled partitions correctly. The only time it really looks at the file, is if you try to rebuild the partition I believe... and some other circumstance that dosn't come to mind. Sam Bingner -Original Message- From: Alex Bligh - linux-kernel [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 15, 2001 11:30 AM To: Linus Torvalds; Jonathan Lundell Cc: Jeff Garzik; James Simmons; Alan Cox; Neil Brown; H. Peter Anvin; Linux Kernel Mailing List; [EMAIL PROTECTED]; Alex Bligh - linux-kernel Subject: Re: LANANA: To Pending Device Number Registrants > The argument that "if you use numbering based on where in the SCSI chain > the disk is, disks don't pop in and out" is absolute crap. It's not true > even for SCSI any more (there are devices that will aquire their location > dynamically), and it has never been true anywhere else. Give it up. Q: Let us assume you have dynamic numbering disk0..N as you suggest, and you have some s/w RAID of SCSI disks. A disk fails, and is (hot) removed. Life continues. You reboot the machine. Disks are now numbered disk0..(N-1). If the RAID config specifies using disk0..N thusly, it is going to be very confused, as stripes will appear in the wrong place. Doesn't that mean the file specifying the RAID config is going to have to enumerate SCSI IDs (or something configuration invariant) as opposed to use the disk0..N numbering anyway? Sure it can interrogate each disk0..N to see which has the ID that it actually wanted, but doesn't this rather subvert the purpose? IE, given one could create /dev/disk/?.+, isn't the important argument that they share common major device numbers etc., not whether they linearly reorder precisely to 0..N as opposed to have some form of identifier guaranteed to be static across reboot & config change. -- Alex Bligh - 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/
New generic HDLC available
Hi, I've put new experimental version of my generic HDLC code on http://hq.pm.waw.pl/hdlc/ ( ftp://ftp.pm.waw.pl/pub/linux/hdlc/experimental/ ) Currently supported (hw drivers) are C101 and N2 (untested) boards. Protocols supported: - X.25 and PPP (via X.25 and syncppp routines) - Frame Relay (CCITT and ANSI LMI, or no LMI) - Cisco HDLC - raw HDLC (you can select NRZ/NRZI/Manchester/FM codes and parity) This version uses new ioctl interface. Comments welcome. No HDLC/FR bridging code yet. No Cisco LMI support (for FR) yet. No docs (except Documentation/networking/generic-hdlc.txt) yet. I'm thinking about implementing asynchronous HDLC driver. The patch has been generated against 2.4.4-ac6 tree. It should apply to pure 2.4.4 as well. Protocol support is now split into separate files hdlc_fr.c, hdlc_cisco.c etc. -- Krzysztof Halasa Network Administrator - 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: LANANA: To Pending Device Number Registrants
On Wednesday 16 May 2001 01:16, David Brownell wrote: >Only if it's augmented by additional device IDs, such as the >"what 's the physical connection for this interface" sort of >primitive that's been mentioned. >[...] > I suppose that for network interface names, some convention for > interface ioctls would suffice to solve that "identify" step. PCI > devices would return the slot_name, USB devices need something > like a patch I posted to linux-usb-devel a few months back. At this point of the discussion I would like to point to the Device Registry patch (http://www.tjansen.de/devreg) that already solves these problems and offers stable device ids for the identification of devices and finding their /dev nodes. The devreg device id has four components: the bus identifier, the location of the device (for pci bus number and slot number, for usb the bus number and a list of port numbers), a model (product and device id) and, if available, a serial number. With the matching algorithm from the libdevreg library you can correctly identifiy after a hotplug action or reboot - each device that has a serial numberas most of the better USB devices do, even if it location has changed - a device without a serial number whose location has not changed If you have a device without serial number and you changed its location the device id can be used for a guess that is correct as long as you dont have two devices of the same kind (same product and vendor ids). bye... - 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: LANANA: To Pending Device Number Registrants
OK, just correct me if I get this wrong, but this code is taking the LAST 2
characters of the device name and verifying that it is "cd". Which would
mean that the standard states that "/dev/ginsucd" would be a CD-ROM drive?
That is why I feel a "name" of a device handle shouldnt set how a driver
operates in this fashion... if you make a small error in your compare, you
might try to eject a Ginsu Cabbage Dicer instead of a cdrom drive... OOPS!
Sam Bingner
Alan Cox writes:
> > len = readlink ("/proc/self/3", buffer, buflen);
> > if (strcmp (buffer + len - 2, "cd") != 0) {
> > fprintf (stderr, "Not a CD-ROM! Bugger off.\n");
> > exit (1);
>
> And on my box cd is the cabbage dicer whoops
Actually, no, because it's guaranteed that a trailing "/cd" is a
CD-ROM. That's the standard.
Regards,
Richard
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
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: /dev/sch0 interface
On Tue, May 15, 2001 at 03:08:01PM -0600, Jeff V. Merkey wrote: > > > Is anyone actuaslly using the /dev/sch0 interface for SCSI tape changers > in Linux? I noticed that the device definitions are present, but I do not > see any driver shipped in the standard base that actually uses it. http://www.in-berlin.de/User/kraxel/linux.html works very well here (needs a minor #include to compile correctly, though) I actually wonder why this isn't in the mainline kernel. > > Thanks > > Jeff > Thorsten -- | Thorsten KranzkowskiInternet: [EMAIL PROTECTED]| | Mobile: ++49 170 1876134 Snail: Niemannsweg 30, 49201 Dissen, Germany | | Ampr: dl8bcu@db0lj.#rpl.deu.eu, [EMAIL PROTECTED] [44.130.8.19] | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5pre2aa1
On Tue, 15 May 2001, Andrea Arcangeli wrote: > Detailed description of 2.4.5pre2aa1 follows. > 00_buffer-2 > > Reschedule during oom while allocating buffers, still getblk > can deadlock with oom but this will hide it pretty well as > it won't loop in a tight loop anymore. These descriptions are very helpful. Are they available somewhere for all your (recent) patches? regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - 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: LANANA: To Pending Device Number Registrants
According to Alan Cox: > Chip: > > Wouldn't it be better just to *try* ioctls and see which ones work and > > which ones don't? > > 1. We have overlaps We all agree that overlaps need to be eliminated over time. In the meantime, as a coping strategy: I'll bet you that for any two given device classes, there is at least one ioctl that works on only one of them. (I'm only talking about an interim workaround! Calm down! Put down those bats!) > 2. I've seen code where people play clever ioctl tricks to deduce a > device type and it ends up looking like one of those chemistry > identification charts (hopefully minus do you see smoke ?) I don't mean to suggest that ioctls be used to deduce device types (except in the case of overlapping ioctl numbers, which shouldn't be all *that* common (I hope)). I mean to suggest that the question "What device type are you?" usually shouldn't even be asked! If you want to do X to the device on fd, just call ioctl(fd, X, ...). Either it works or it doesn't. I realize that overlapping ioctls throw a monkey wrench into this world view. Is it a bigger wrench than the wrenching pain that we'll have to live through to make device identification reliable? Depends on how many ioctls overlap, and how easily we could make them stop overlapping. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - 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: LANANA: To Pending Device Number Registrants
On Tue, 15 May 2001, David Brownell wrote: > I suppose that for network interface names, some convention for > interface ioctls would suffice to solve that "identify" step. PCI > devices would return the slot_name, USB devices need something > like a patch I posted to linux-usb-devel a few months back. This is crap. For user tools (_especially_ for admin scripts) ioctls are damn inconvenient. I don't have Perl or Python on the root fs. And I don't need yet another binary lurking in /sbin, thank you very much. If you want to do it - do it right. Accessing /dev/eth//MAC is trivial. Wanking with ioctls is not. And populating such tree is as simple as it gets. - 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: LANANA: To Pending Device Number Registrants
[ Re why "physical" device IDs _should_ have a critical role in sysadmin ]
> I would have to agree that "stable" is critical to not driving people
> crazy. In the case of AIX, once a device is enumerated, it will retain
> the same name across reboots. Enough information is kept about each
> device to determine if it has already been enumerated (i.e. same I/O
> port address for serial devices, MAC address for ethernet cards, etc),
> or if it is a new device and should get a new name.
I caught those refs to how AIX does this ... sounds worth learning from.
Does it handle USB "port addresses" (which bus and hub)?
> > Given hotplugging, I think the best solution to such issues
> > does involve exposing topological IDs such as PCI slot names.
> > (What IDs the different applications use is a different issue.)
>
> I disagree here. In many cases you only have a very limited number of
> devices of each type (or only 1), so you don't want to be bogged down
> with physical device naming.
I'm not clear what you were disagreeing with. Though I think you've
hit on an important stumbling block: folk working with only one instance
of a given device type tend to come at this problem from a differerent
perspective. A workable naming policy needs to not make such setups
become painful; they're the "start points" most systems will grow from.
> If you have lots of a given type of device
> (e.g. disks), you _also_ don't want to be bogged down with physical
> device naming, because it will NOT be consistent across different physical
> access methods. In both cases, you want a generic name PLUS a way to
> find out the physical characteristics (attributes) of the device to do
> INITIAL configuration. If the device keeps a constant name across
> reboots, you don't care how it is accessed after the first configuration.
Sounds like you're actually agreeing with me that the ID used by
applications ("generic name") isn't necessarily the physical/topological ID
used to establish and maintain a stable non-"crazy" naming setup.
- Dave
-
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: LANANA: To Pending Device Number Registrants
Chip Salzenberg wrote: > According to Alan Cox: > > Given a file handle 'X' how do I find out what ioctl groups I should > > apply to it. > > Wouldn't it be better just to *try* ioctls and see which ones work and > which ones don't? As ioctl's is just numbers that can be valid but mean totally different thing depending on device I don't see how this is going to work. It took me close to a month to figure out why my new 1rpm scsi disk constantly ended up with a read only filesystem. What I did not know at that time was that the /dev/sg[x] numbering was changed by adding something to the scsi chain and my backup software now sent the eject command to the disk instead of to the tape. This ioctl means spinn down when it is sent to the disk and that in turn produces a fatal error and a remount to ro for the mounted filesystem. This problem had not existed for me if things had been mapped more static this i why I'am not overly happy hearing that things is going to be even more volatile. But I guess that it's possible to solve most of this issues in userspace. One way of looking on the problem is to take it to it's logical extrem. This would be a kernel with no persistent storage for devices no major,minor and no name policy. The kernel would simply put any device it finds in /dev/devno/[x] where x is just a number that should be seen as something that changed for every reboot. Any userspace solution that can create device links that are stable out of this is one that would get my vote. This obviously needs some type if standard why to query the devices or else it's no way it can work. - 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: LANANA: To Pending Device Number Registrants
> > The "eth0..N" naming is done RIGHT! Only if it's augmented by additional device IDs, such as the "what 's the physical connection for this interface" sort of primitive that's been mentioned. > Nothing to do with the kernel but, one should then argue that the > current stuff in /etc/sysconfig/network-scripts is broken for hotplug as > placing a new network adapter into your bus will renumber your interfaces > causing them to be ifconfig'd wrongly. Not just hotplug -- any configuration where these identifiers can change "meaning" (which physical device?) over time. For example, adding/removing/swapping hardware does it too. > You'd want to associate the IP > configuration stuff with the particular network interface, by MAC address. Bob Glamm had the right sort of idea: if the kernel is going to be assigning tool-visible device names, the tools need to have and use additional device metadata, perhaps like this: > # start up networking >for i in eth0 eth1 eth2; do >identify device $i >get configuration/config procedure for device $i identity >configure $i >done In fact that "identify" step is probably worth enabling for EVERY (!) device, not just network interfaces. (Which, since they don't show up with major/minor device numbers today, are perhaps a bit offtopic for the original thrust of this thread ... :) I suppose that for network interface names, some convention for interface ioctls would suffice to solve that "identify" step. PCI devices would return the slot_name, USB devices need something like a patch I posted to linux-usb-devel a few months back. - Dave - 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: LANANA: To Pending Device Number Registrants
David Bronwell writes: > Linus writes: > > Now, if we just fundamentally try to think about any device as being > > hot-pluggable, you realize that things like "which PCI slot is this device > > in" are completely _worthless_ as device identification, because they > > fundamentally take the wrong approach, and they don't fit the generic > > approach at all. > > The reason is that such "physical" identifiers (or "device topology" IDs) > may be all that's available to distinguish some devices. For example, > network adapters (no major/minor numbers :) and parallel/printer/serial > ports may have no better "stable" (over reboots) identifier available. I would have to agree that "stable" is critical to not driving people crazy. In the case of AIX, once a device is enumerated, it will retain the same name across reboots. Enough information is kept about each device to determine if it has already been enumerated (i.e. same I/O port address for serial devices, MAC address for ethernet cards, etc), or if it is a new device and should get a new name. > Without "stable" names, it's too easy to have bad things happen, like > your "confidential materials" printer output get redirected into the > lobby printer, or trust your network DMZ as if it were the internal > network. Without stable names it is basically impossible to make any sort of reasonable configuration decision, unless the configuration can be stored on the device itself. That works for disks, and not much else. > Given hotplugging, I think the best solution to such issues > does involve exposing topological IDs such as PCI slot names. > (What IDs the different applications use is a different issue.) I disagree here. In many cases you only have a very limited number of devices of each type (or only 1), so you don't want to be bogged down with physical device naming. If you have lots of a given type of device (e.g. disks), you _also_ don't want to be bogged down with physical device naming, because it will NOT be consistent across different physical access methods. In both cases, you want a generic name PLUS a way to find out the physical characteristics (attributes) of the device to do INITIAL configuration. If the device keeps a constant name across reboots, you don't care how it is accessed after the first configuration. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: FW: I think I've found a serious bug in AMD Athlon page_alloc.c routines, where do I mail the developer(s) ?
Hi Alan, Thanks for getting back to me. I wonder if DFI has a bios or chipset patch available and whether that would help ? Maybe disabling the VIA chipset support in the kernel and running generic drivers would help ? Thanks. Keep up the good work anyways ! Regards David Wilson Technical Support Centre The S.A Internet 0860 100 869 http://www.sai.co.za -Original Message- From: Alan Cox [mailto:[EMAIL PROTECTED]] Sent: 16 May 2001 12:54 To: David Wilson Subject: Re: FW: I think I've found a serious bug in AMD Athlon page_alloc.c routines, where do I mail the developer(s) ? Known funny. Only shows up on via chipset boards. Right now we think but have not proven its a hardware flaw somwhere - 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: FW: I think I've found a serious bug in AMD Athlon page_alloc.croutines, where do I mail the developer(s) ?
> I think I've found a serious bug in AMD Athlon page_alloc.c routines in there's nothing athlon-specific there. > correct on the DFI AK75-EC motherboard, if I set the CPU kernel type to 586 > everything is 100%, if I use "Athlon" kernel type I get: > kernel BUG at page_alloc.c:73 when you select athlon at compile time, you're mainly getting Arjan's athlon-specific page-clear and -copy functions (along with some relatively trivial alignment changes). these functions are ~3x as fast as the generic ones, and seem to cause dram/cpu-related oopes on some machines. in short: faster code pushes the hardware past stability. there's no reason, so far, to think that there's anything wrong with the code - Alan had a possible issue with prefetching and very old Atlons, but the people reporting problems like this are actually running kt133a and new fsb133 Athlons. > I've changed RAM, Motherboard etc... still the same. changed to a non-kt133a board? how about running fsb and/or dram at 100, rather than 133? > Also the same system runs linux-2.2.16 100% 2.2 doesn't have the fast page-clear and -copy code afaik. afaik, there are *no* problems on kt133 machines, and haven't heard any pain from people who might have Ali Magic1, AMD 760 or KT266 boards, but they're still rare. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PATCH: export linux_logo_bw for hgafb.c
Here is a patch for 2.4.4. linux_logo_bw is used in hgafb.c, which can be compiled as a module. But linux_logo_bw is not exported. H.J. --- --- linux-2.4.4-ac9/drivers/video/fbcon.c.mod Tue May 15 15:39:17 2001 +++ linux-2.4.4-ac9/drivers/video/fbcon.c Tue May 15 15:40:18 2001 @@ -2495,3 +2495,4 @@ EXPORT_SYMBOL(fbcon_redraw_bmove); EXPORT_SYMBOL(fbcon_redraw_clear); EXPORT_SYMBOL(fbcon_dummy); EXPORT_SYMBOL(fb_con); +EXPORT_SYMBOL(linux_logo_bw); - 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: megaraid problems
> it refuses to show any drives and i cant get the management > software to work. so my question is this: > has anyone with this card gotten it to work under linux > 2.4.4-acX? if so, how? Mine works. In fact the 2.4.4ac source tree currently lives on it. - 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: LANANA: To Pending Device Number Registrants
> > Graphics cards are the same way. Especially high end ones. They have pipes > > as well. For low end cards you can think of them as single pipeline cards > > with one pipe. > > It still frosts my shorts that DRM (e.g. /dev/dri/card0) doesn't use > write(). It's a natural way to feed pipelines. But no, it's a raft > of ioctl() calls. *sigh* I never liked this either. ioctl calls are slooow. - 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: this LANA thing
> This way you can detect new disks, adapter cards, serial ports, etc. any > time after the system is up. All disks are identified as "/dev/hdiskX", I bet it will go in as /dev/hdiscX ;-) (I prefer disk) But I wish you to not vanish the scheme in which one can also address a given device by its location. Confer devfs: /dev/discs/disc0 to /dev/ide/bus... Because I really sometimes wish to address my harddisks, and not some logical crap. -mirabilos -- by telnet - 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/
megaraid problems
Hi, I have a megaraid 466 controller, which both ami and the linux kernel say is supported under 2.4.4, I tried the ami patches to the drivers in the vanilla kernel to no avail, the card works under windows...the card is even detected under linux now, but it refuses to show any drives and i cant get the management software to work. so my question is this: has anyone with this card gotten it to work under linux 2.4.4-acX? if so, how? I have read about many people upgrading firmware and using 'latest drivers' both of which i have done, so i am at a loss here. any help is appreciated. --gabe -- "It's not brave if you're not scared." - 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: LANANA: To Pending Device Number Registrants
> According to Alan Cox: > > Given a file handle 'X' how do I find out what ioctl groups I should > > apply to it. > > Wouldn't it be better just to *try* ioctls and see which ones work and > which ones don't? You can do this with the tty layer. Just open /dev/tty and try tioclinux. On my serial console it fails and when I run the exact same program works on my VT. It is the only way to see if these ioctl calls work. No other way to see if your on a serial console or a VT. - 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: LANANA: To Pending Device Number Registrants
> > > I couldn't agree with you more. It gives me headaches at work. One note, > > > their is a except to the eth0 thing. USB to USB networking. It uses usb0, > > > etc. I personally which they use eth0. > > > > USB to USB networking cables aren't ethernet. > > I'm talking about a wireless connection. ipaq USB cradle to PC. Sounds rather wire-ful to me ... :) It's not an Ethernet, which is why it doesn't masquerade as one. At least, not more than necessary to interop with at least one set of Win32 drivers. (And one hopes, more in the future.) Until there's some way that network interfaces can expose more information to sysadmin tools, it seems smarter to set things up so they can't confuse USB and Ethernet links. Scripts can "know" the various differences, and accomodate more. One example that's come up: an MTU closer to two USB 1.1 frames will give better throughput at negligible cost, other than precluding some bridging setups involving N-BaseT. - Dave - 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: LANANA: To Pending Device Number Registrants
Alex Bligh writes:
> Q: Let us assume you have dynamic numbering disk0..N as you suggest,
>and you have some s/w RAID of SCSI disks. A disk fails, and is (hot)
>removed. Life continues. You reboot the machine. Disks are now numbered
>disk0..(N-1). If the RAID config specifies using disk0..N thusly, it
>is going to be very confused, as stripes will appear in the wrong place.
But this already happens with the SCSI device numbering, so no big change.
It would also happen if you have multi-path access to the RAID box (i.e.
two SCSI controllers), or with FC where there IS no "physical address",
or move the disks to a different type of SCSI controller (with a different
detection order than other controllers in the system), etc.
>Doesn't that mean the file specifying the RAID config is going to have
>to enumerate SCSI IDs (or something configuration invariant) as
>opposed to use the disk0..N numbering anyway?
No such thing as configuration invariant in some cases.
>Sure it can interrogate each disk0..N to see which has the ID that
>it actually wanted, but doesn't this rather subvert the purpose?
Not at all. To be robust, the (software) RAID system should ONLY access
disks that it knows belong to a given RAID set. To do otherwise is
useless. This is what LVM does, and it surprises me if MD RAID does
anything else (never really looked into it...).
In any case, a sane system would likely not expose all of the underlying
disks that make up a RAID set as a "disk", after that RAID set was built.
At configuration time, any /dev/disk{A,B,C} that went into the RAID
set would be removed, and the resulting RAID volume would become a new
/dev/diskX, just like any other disk in the system. If you really needed
more information about the RAID configuration, use the RAID tools to
query the attributes of /dev/diskX. That would solve a _lot_ of problems
with disks that make up meta-volumes being accessed via /dev/hdX instead
of /dev/mdY.
> IE, given one could create /dev/disk/?.+, isn't the important
> argument that they share common major device numbers etc., not whether
> they linearly reorder precisely to 0..N as opposed to have some form
> of identifier guaranteed to be static across reboot & config change.
I don't think the objective is necessarily to have a _packed_ device
numbering, nor one that changes randomly after each reboot, but just a
generic device naming independent of physical location, access method, etc.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Exporting symbols from a module.
Anders Fugmann writes: > I'm not sure where to put this in my Makefile. > (tried, but it did not help) > Could you please send an example. See fs/Makefile or fs/msdos/Makefile for examples. I assume you are building your module under the kernel tree? Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
FW: I think I've found a serious bug in AMD Athlon page_alloc.c routines, where do I mail the developer(s) ?
Hi all, howzit going ? ;-) Maybe I'm being dumb but I've been working with Linux long enough not to make a silly mistake *I hope*. I think I've found a serious bug in AMD Athlon page_alloc.c routines in kernel 2.4.4. I'm running an AMD athlon 850 running at 100x8.5, everything is setup correct on the DFI AK75-EC motherboard, if I set the CPU kernel type to 586 everything is 100%, if I use "Athlon" kernel type I get: kernel BUG at page_alloc.c:73 The system then dies with: exit mmap: map count is 13 I also get various "unable to handle paging requests" etc. etc. I've changed RAM, Motherboard etc... still the same. Also the same system runs linux-2.2.16 100% I'm not subscribed to [EMAIL PROTECTED], so please cc me in your reply to the list. Thanks. Regards David Wilson Technical Support Centre The S.A Internet 0860 100 869 http://www.sai.co.za - 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: LANANA: To Pending Device Number Registrants
Alan Cox wrote: > > > 1. is of course a problem in itself. Someone who creates overlapping > > ioctls should be spanked, hard. > > No argument there. But there is no LANANA ioctl body > I though Michael Chastain was maintaining this set. No, we haven't made it an official LANANA function, mostly because I didn't want to push. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Getting FS access events
"Albert D. Cahalan" wrote: > > H. Peter Anvin writes: > > > This would leave no way (without introducing new interfaces) to write, > > for example, the boot block on an ext2 filesystem. Note that the > > bootblock (defined as the first 1024 bytes) is not actually used by > > the filesystem, although depending on the block size it may share a > > block with the superblock (if blocksize > 1024). > > The lack of coherency would screw this up anyway, doesn't it? > You have a block device, soon to be in the page cache, and > a superblock, also soon to be in the page cache. LILO writes to > the block device, while the ext2 driver updates the superblock. > Whatever gets written out last wins, and the other is lost. > Albert, I *did* say "this better work or we have a problem." -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
> Even if we have per-device filesystems, we are going to have the same > issue, in one form or another. If we have a "/devicetype" trailing > component added on, then somewhere it has to report "CD-ROM" or "cd" > or "Compact Disc". When I ask it. Not when I name it - 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: LANANA: To Pending Device Number Registrants
On Tue, 15 May 2001, Richard Gooch wrote: > Me The device name authority (Peter). Whoever. If you want > Peter to bless it, then fine. But the standard is there. Violators > will be persecuted. Ah, standard on names in devfs? About as relevant as GOSIP... - 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: LANANA: To Pending Device Number Registrants
> > >Keep it informational. And NEVER EVER make it part of the design. > > > > What about: > > > > 1 (network domain). I have two network interfaces that I connect to > > two different network segments, eth0 & eth1; > > So? > > Informational. You can always ask what "eth0" and "eth1" are. [...] > The location of the device is _meaningless_. [...] Roast me if I'm wrong or if this has been beat to death, but there seem to be two sides of the issue here: 1) Device numbering/naming. It is immaterial to the kernel how the devices are enumerated or named. In fact, I would argue that the naming could be non-deterministic across reboots. 2) Device identification. The end-user or user-space software needs to be able to configure certain devices a certain way. They too don't (shouldn't) care what numbers or names are given to the devices, as long as they can configure the proper device correctly. I don't disagree that a move toward making the move toward dynamic device enumeration/naming is the right way to go; in fact, I don't disagree that a 32-bit dev_t would be more than adequate (and sparse) for most configurations - even the largest configured machines wouldn't have more than several million device names/nodes. However, I *do* see that there is a LOT of end-user software that still depends on static numbering to partially identify devices. Yes, it is half-baked that major 8 gets you SCSI devices, and then after you open all the minor devices you STILL get to do all the device-specific ioctl() calls to identify the device capabilities of the controller or each target on the controller. But I don't think that arbitrarily slamming the door on static naming/numbering to force people to change arguably broken code or semantics is the right move to make either. Instead, what about doing the transformation gradually? Static and dyanmic enumeration shouldn't have to be mutually exclusive. E.g. in the interim devices could be accessed via dynamically enumerated/named nodes as well as the old staticially enumerated/named nodes. The current device enumeration space seems be sparse enough to take care of this for most cases. During this transition, end-user software would have the chance to be re-written to use the new dynamically enumerated/named device scheme, perhaps with a somewhat standardized interface to make identification and capability detection of devices easier from software. At some scheduled point in future kernel development support for the old static enumeration/naming scheme would be dropped. Finally, there has to be an *easy* way of identifying devices from software. You're right, I don't care if my network cards are numbered 0-1-2, 2-0-1, or in any other permutation, *as long as I can write something like this*: # start up networking for i in eth0 eth1 eth2; do identify device $i get configuration/config procedure for device $i identity configure $i done Ideally, the identity of device $i would remain the same across reboots. Note that the device isn't named by its identity, rather, the identity is acquired from the device. This gets difficult for certain situations but I think those situations are rare. Most modern hardware I've seen has some intrinsic identification built on board. > Linux gets this right. We don't give 100Mbps cards different names from > 10Mbps cards - and pcmcia cards show up in the same namespace as cardbus, > which is the same namespace as ISA. And it doesn't matter what _driver_ we > use. > > The "eth0..N" naming is done RIGHT! > > > 2 (disk domain). I have multiple spindles on multiple SCSI adapters. > > So? Same deal. You don't have eth0..N, you have disk0..N. [...] > Linux gets this _somewhat_ right. The /dev/sdxxx naming is correct (or, if > you look at only IDE devices, /dev/hdxxx). The problem is that we don't > have a unified namespace, so unlike eth0..N we do _not_ have a unified > namespace for disks. This numbering seems to be a kernel categorization policy. E.g., I have k eth devices, numbered eth0..k-1. I have m disks, numbered disc0..m-1, I have n video adapters, numbered fb0..n-1, etc. This implies that at some point someone will have to maintain a list of device categories. IMHO the example isn't consistent though. ethXX devices are a different level of classification from diskYY. I would argue that *all* network devices should be named net0, net1, etc., be they Ethernet, Token Ring, Fibre Channel, ATM. Just as different disks be named disk0, disk1, etc., whether they are IDE, SCSI, ESDI, or some other controller format. -Bob - 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: LANANA: To Pending Device Number Registrants
Richard Gooch wrote: > > Even if we have per-device filesystems, we are going to have the same > issue, in one form or another. If we have a "/devicetype" trailing > component added on, then somewhere it has to report "CD-ROM" or "cd" > or "Compact Disc". > Again, many device types aren't mutually exclusive. It's a set, not an enum. -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Getting FS access events
H. Peter Anvin writes: > This would leave no way (without introducing new interfaces) to write, > for example, the boot block on an ext2 filesystem. Note that the > bootblock (defined as the first 1024 bytes) is not actually used by > the filesystem, although depending on the block size it may share a > block with the superblock (if blocksize > 1024). The lack of coherency would screw this up anyway, doesn't it? You have a block device, soon to be in the page cache, and a superblock, also soon to be in the page cache. LILO writes to the block device, while the ext2 driver updates the superblock. Whatever gets written out last wins, and the other is lost. - 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: LANANA: To Pending Device Number Registrants
> 1. is of course a problem in itself. Someone who creates overlapping > ioctls should be spanked, hard. No argument there. But there is no LANANA ioctl body > Agreed, but "determining type of device" and "determining if interface X > is available on this device" are different operations. If the latter is > what you want, you want to *explicitly* perform the latter operation. Both should be clean and explicit - 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: LANANA: To Pending Device Number Registrants
> And my opinion is that the "hot-plugged" approach works for devices even > if they are soldered down ... Yep. Though I tend to look at the whole problem as "autoconfiguration" lately. Solving device naming (even the major/minor subproblem) is only one part of having a complete autoconfiguration infrastructure. > Now, if we just fundamentally try to think about any device as being > hot-pluggable, you realize that things like "which PCI slot is this device > in" are completely _worthless_ as device identification, because they > fundamentally take the wrong approach, and they don't fit the generic > approach at all. Well, "completely" goes too far IMO. Unless by "identifier" you imply something of which there's only one? In my book, devices can have many kinds of identifiers. The reason is that such "physical" identifiers (or "device topology" IDs) may be all that's available to distinguish some devices. For example, network adapters (no major/minor numbers :) and parallel/printer/serial ports may have no better "stable" (over reboots) identifier available. Without "stable" names, it's too easy to have bad things happen, like your "confidential materials" printer output get redirected into the lobby printer, or trust your network DMZ as if it were the internal network. Given hotplugging, I think the best solution to such issues does involve exposing topological IDs such as PCI slot names. (What IDs the different applications use is a different issue.) - Dave - 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: LANANA: To Pending Device Number Registrants
Alan Cox writes:
> > > > if (strcmp (buffer + len - 2, "cd") != 0) {
> > > > fprintf (stderr, "Not a CD-ROM! Bugger off.\n");
> > > > exit (1);
> > >
> > > And on my box cd is the cabbage dicer whoops
> >
> > Actually, no, because it's guaranteed that a trailing "/cd" is a
> > CD-ROM. That's the standard.
>
> And its back to /dev/disc versus /dev/disk. Dont muddle user picked
> file names with kernel namespace bindings please.
Even if we have per-device filesystems, we are going to have the same
issue, in one form or another. If we have a "/devicetype" trailing
component added on, then somewhere it has to report "CD-ROM" or "cd"
or "Compact Disc".
Regards,
Richard
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
Richard Gooch wrote:
>
> Alexander Viro writes:
> >
> >
> > On Tue, 15 May 2001, Richard Gooch wrote:
> >
> > > Alan Cox writes:
> > > > > len = readlink ("/proc/self/3", buffer, buflen);
> > > > > if (strcmp (buffer + len - 2, "cd") != 0) {
> > > > > fprintf (stderr, "Not a CD-ROM! Bugger off.\n");
> > > > > exit (1);
> > > >
> > > > And on my box cd is the cabbage dicer whoops
> > >
> > > Actually, no, because it's guaranteed that a trailing "/cd" is a
> > > CD-ROM. That's the standard.
> >
> > Set by...?
>
> Me The device name authority (Peter). Whoever. If you want
> Peter to bless it, then fine. But the standard is there. Violators
> will be persecuted.
>
No, bad designers will be persecuted. This is bad design.
-hpa
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
Alexander Viro writes:
>
>
> On Tue, 15 May 2001, Richard Gooch wrote:
>
> > Alan Cox writes:
> > > > len = readlink ("/proc/self/3", buffer, buflen);
> > > > if (strcmp (buffer + len - 2, "cd") != 0) {
> > > > fprintf (stderr, "Not a CD-ROM! Bugger off.\n");
> > > > exit (1);
> > >
> > > And on my box cd is the cabbage dicer whoops
> >
> > Actually, no, because it's guaranteed that a trailing "/cd" is a
> > CD-ROM. That's the standard.
>
> Set by...?
Me The device name authority (Peter). Whoever. If you want
Peter to bless it, then fine. But the standard is there. Violators
will be persecuted.
Regards,
Richard
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
> Type of filesystem where the file came from? Sure. Who says it comes from only one - even on devfs that is not true /dev/disk/4 is quite possibly disk scsi-disk scsi-device usb-scsi-device usb-device all at once - 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: Exporting symbols from a module.
Hi. Thanks for your reply. I'm not sure where to put this in my Makefile. (tried, but it did not help) Could you please send an example. Thanks in advance. Anders Fugmann Andreas Dilger wrote: >> > I just recently had this problem, and your Makefile is missing: > > export-objs := .o > > where .o is the compiled object file from .c, and > not the module name (if it is different). > > Cheers, Andreas > - 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: LANANA: To Pending Device Number Registrants
> > > if (strcmp (buffer + len - 2, "cd") != 0) {
> > > fprintf (stderr, "Not a CD-ROM! Bugger off.\n");
> > > exit (1);
> >
> > And on my box cd is the cabbage dicer whoops
>
> Actually, no, because it's guaranteed that a trailing "/cd" is a
> CD-ROM. That's the standard.
And its back to /dev/disc versus /dev/disk. Dont muddle user picked file
names with kernel namespace bindings please.
-
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: LANANA: To Pending Device Number Registrants
Alan Cox wrote: > > > Wouldn't it be better just to *try* ioctls and see which ones work and > > which ones don't? > > 1. We have overlaps > 1. is of course a problem in itself. Someone who creates overlapping ioctls should be spanked, hard. > 2. I've seen code where people play clever ioctl tricks to deduce a device > type and it ends up looking like one of those chemistry identification > charts (hopefully minus do you see smoke ?) > > It should be clean and explicit Agreed, but "determining type of device" and "determining if interface X is available on this device" are different operations. If the latter is what you want, you want to *explicitly* perform the latter operation. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
> Wouldn't it be better just to *try* ioctls and see which ones work and > which ones don't? 1. We have overlaps 2. I've seen code where people play clever ioctl tricks to deduce a device type and it ends up looking like one of those chemistry identification charts (hopefully minus do you see smoke ?) It should be clean and explicit - 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: LANANA: To Pending Device Number Registrants
> I couldn't agree with you more. It gives me headaches at work. One note, > their is a except to the eth0 thing. USB to USB networking. It uses usb0, > etc. I personally which they use eth0. > The packet framing is quite different so it doesnt really make sense. For wireless it does use ethernet packet format so it makes sense - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] SMP-safe lock_super()
Patch turns s_lock+s_wait combination into semaphore.
wait_on_super() is dead. lock_super() is down(>s_lock),
unlock_super() is up(...).
One place is still ugly - get_super(), but that'll have to
wait until we add reference counters on superblocks. For the time being
get_super() behaviour stays unchanged (i.e. all races with umount()
are still there).
Please, apply it - it doesn't break anything in tree,
unlikely to break anything 3rd-party and any potential breakage there
will be caught by compiler.
Al
diff -urN S5-pre2/fs/ext2/super.c S5-pre2-s_lock/fs/ext2/super.c
--- S5-pre2/fs/ext2/super.c Sat Apr 28 02:12:56 2001
+++ S5-pre2-s_lock/fs/ext2/super.c Tue May 15 18:12:35 2001
@@ -76,9 +76,6 @@
va_start (args, fmt);
vsprintf (error_buf, fmt, args);
va_end (args);
- /* this is to prevent panic from syncing this filesystem */
- if (sb->s_lock)
- sb->s_lock=0;
sb->s_flags |= MS_RDONLY;
panic ("EXT2-fs panic (device %s): %s: %s\n",
bdevname(sb->s_dev), function, error_buf);
diff -urN S5-pre2/fs/reiserfs/prints.c S5-pre2-s_lock/fs/reiserfs/prints.c
--- S5-pre2/fs/reiserfs/prints.cSat Apr 28 02:12:56 2001
+++ S5-pre2-s_lock/fs/reiserfs/prints.c Tue May 15 18:12:35 2001
@@ -349,8 +349,6 @@
#endif
/* this is to prevent panic from syncing this filesystem */
- if (sb && sb->s_lock)
-sb->s_lock=0;
if (sb)
sb->s_flags |= MS_RDONLY;
diff -urN S5-pre2/fs/super.c S5-pre2-s_lock/fs/super.c
--- S5-pre2/fs/super.c Tue May 15 03:51:04 2001
+++ S5-pre2-s_lock/fs/super.c Tue May 15 18:12:35 2001
@@ -580,30 +580,7 @@
#undef MANGLE
#undef FREEROOM
}
-
-/**
- * __wait_on_super - wait on a superblock
- * @sb: superblock to wait on
- *
- * Waits for a superblock to become unlocked and then returns. It does
- * not take the lock. This is an internal function. See wait_on_super().
- */
-void __wait_on_super(struct super_block * sb)
-{
- DECLARE_WAITQUEUE(wait, current);
-
- add_wait_queue(>s_wait, );
-repeat:
- set_current_state(TASK_UNINTERRUPTIBLE);
- if (sb->s_lock) {
- schedule();
- goto repeat;
- }
- remove_wait_queue(>s_wait, );
- current->state = TASK_RUNNING;
-}
-
/*
* Note: check the dirty flag before waiting, so we don't
* hold up the sync while mounting a device. (The newly
@@ -648,7 +625,9 @@
s = sb_entry(super_blocks.next);
while (s != sb_entry(_blocks))
if (s->s_dev == dev) {
- wait_on_super(s);
+ /* Yes, it sucks. As soon as we get refcounting... */
+ lock_super(s);
+ unlock_super(s);
if (s->s_dev == dev)
return s;
goto restart;
@@ -700,9 +679,7 @@
s = sb_entry(s->s_list.next)) {
if (s->s_dev)
continue;
- if (!s->s_lock)
- return s;
- printk("VFS: empty superblock %p locked!\n", s);
+ return s;
}
/* Need a new one... */
if (nr_super_blocks >= max_super_blocks)
@@ -714,10 +691,14 @@
INIT_LIST_HEAD(>s_dirty);
INIT_LIST_HEAD(>s_locked_inodes);
list_add (>s_list, super_blocks.prev);
- init_waitqueue_head(>s_wait);
INIT_LIST_HEAD(>s_files);
INIT_LIST_HEAD(>s_mounts);
init_rwsem(>s_umount);
+ sema_init(>s_lock, 1);
+ sema_init(>s_vfs_rename_sem,1);
+ sema_init(>s_nfsd_free_path_sem,1);
+ sema_init(>s_dquot.dqio_sem, 1);
+ sema_init(>s_dquot.dqoff_sem, 1);
}
return s;
}
@@ -734,11 +715,7 @@
s->s_bdev = bdev;
s->s_flags = flags;
s->s_dirt = 0;
- sema_init(>s_vfs_rename_sem,1);
- sema_init(>s_nfsd_free_path_sem,1);
s->s_type = type;
- sema_init(>s_dquot.dqio_sem, 1);
- sema_init(>s_dquot.dqoff_sem, 1);
s->s_dquot.flags = 0;
s->s_maxbytes = MAX_NON_LFS;
lock_super(s);
diff -urN S5-pre2/fs/ufs/super.c S5-pre2-s_lock/fs/ufs/super.c
--- S5-pre2/fs/ufs/super.c Sat Apr 28 02:12:56 2001
+++ S5-pre2-s_lock/fs/ufs/super.c Tue May 15 18:12:35 2001
@@ -230,9 +230,6 @@
va_start (args, fmt);
vsprintf (error_buf, fmt, args);
va_end (args);
- /* this is to prevent panic from syncing this filesystem */
- if (sb->s_lock)
- sb->s_lock = 0;
sb->s_flags |= MS_RDONLY;
printk (KERN_CRIT "UFS-fs panic (device %s): %s: %s\n",
kdevname(sb->s_dev), function, error_buf);
diff -urN S5-pre2/include/linux/fs.h S5-pre2-s_lock/include/linux/fs.h
---
Re: 3c900 card and kernel 2.4.3
Juri Haberland wrote: > > Andrew Morton wrote: > > > For non-modular drivers things are less easy. If you > > want to force it to use 10baseT (if_port zero) then > > it should work OK if you cheat and use mem_start=0x400. > > So `ether=0,0,0x400'. > > > > For BNC, it should work just fine with `ether=0,0,1'. > > If it doesn't, please shout at me. Compile the > > driver with `static int vortex_debug = 7;' at line > > 183 and send me the boot logs. > > Hi Andrew, > > I tried it with 'ether=0,0,1', 3 and also 7, but to no avail. The output > of dmesg follows. Oh, and I forgot to say, that the card is actually set to autoselection in the EEPROM (I just had a look with the DOS tool). Juri - 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: LANANA: To Pending Device Number Registrants
On 15 May 2001 13:26:58 -0700, Dan Hollis wrote: > This thread is becoming high enough volume and likely to become much more > so, perhaps a separate ml should be set up for it? linux-device-management > perhaps? I agree that this is going to be a very high-volume discussion. OTOH, this discussion is going to have a fundamental impact on nearly everyong doing driver work in the kernel tree. It's hard for me to conceive of kernel hackers who wouldn't want to track this discussion and thereby gain a much better understanding of the implementation and design issues surrounding Linus driver development. Taking the discussion to another list is likely to fail and would also deprive many of having this information in their faces, which is probably where it belongs. Happy trails, Miles - 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: LANANA: To Pending Device Number Registrants
Chip Salzenberg wrote: > > According to H. Peter Anvin: > > A device can inherently belong to multiple device classes, and it > > really should be thought of as such. > > And then there are layering technologies like LVM and loopback. > They should be included in a discovery, but if you limit yourself > to one "device type", there's no place for them. > > > For example a disk may belong, at the same time, to the "scsi", > > "disk" and "scsi-disk" device classes [...] > > True, but in a sane system, "scsi" + "disk" implies "scsi-disk". > Well, of course, but it's still a separate class. An operation can belong to "scsi-disk" that doesn't belong in either "scsi" or "disk". You can replace the - with an upside-down U if you want; it's not in Latin-1 unfortunately. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to H. Peter Anvin: > A device can inherently belong to multiple device classes, and it > really should be thought of as such. And then there are layering technologies like LVM and loopback. They should be included in a discovery, but if you limit yourself to one "device type", there's no place for them. > For example a disk may belong, at the same time, to the "scsi", > "disk" and "scsi-disk" device classes [...] True, but in a sane system, "scsi" + "disk" implies "scsi-disk". -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.2.20pre2aa1
The main features of 2.2.20pre2aa1 are: o Support for 4Gigabyte of RAM on IA32 (me and Gerhard Wichert) o Support for 2T of RAM on alpha (me) o RAW-IO (doable with bigmem enabled too). Improvements are also been backported from 2.4. o SMP scheduler improvements. (me and partly from 2.3.x contributed by Ingo Molnar) o LFS (>2G file on 32bit architectures) also NFSv3 works over 2G (nfsv3-lfs work from me, Andi and fix from Jay Weber) o fixed race in wake-one LIFO in accept(2). Apache must be compiled with -DSINGLE_LISTEN_UNSERIALIZED_ACCEPT to take advantage of that. o lowlatency and SMP scalability in all copy-user and tcp_sendmsg checksum. o GFS support. o various fixes Detailed description of 2.2.20pre2aa1 follows. --- 00_4_min_percent-1 Increase the min percent of the buffer cache and page cache to 4%. (it wouldn't matter if the VM algorithms were better). (me) 00_IO-wait-3 Avoid suprious unplug of the I/O queue. (me) 00_K7_P4-cachelines-2 Allows the kernel to be compiled for K7 (AMD Athlon) or Pentium4. This compilations options _only_ make the kernel to assume respectively 64byte cachelines or 128byte cachelines. Those assumptions are critical mostly on SMP systems, but even UP will take advantage of it because it will make most performance critical slab allocations to start on a cacheline boundary. Since the only difference between Ppro/K7/P4 compilations is the cacheline size assumed by the kernel you can safely boot a K7/P4 compiled kernel on a Ppro, it won't obviously generate cacheline pinpongs in SMP. There are only two downsides in running on a Ppro (PII/PIII included) a K7/P4 compiled kernel: 1) some byte of memory wasted due the larger paddings (really not a big deal) 2) potential waste of cacheline sets. On PII and PIII and PPro the L1 dcache is 8kbyte or 16kbytes 2-way set associative (so there are 128 or 256 sets of cachelines) and by stressing the first 32bytes of the 128 byte aligned data structures (for example if the kernel is compiled for P4) you would take advantage of only 1/4 of the available L1 cache. (you would stress set 0, 4, 8, ... only) This is probably quite serious issue in terms of performance. So for Ppro/PII/PIII you're still suggested to use Ppro compilation option (if care to optimize the L1 cache usage). (me and Andi) 00_P4-local-APIC-1 Fix a local APIC initaliziation ordering bug that triggers on the PIV. 00_PIII-10.bz2 SSE/SSE2 support (unmasked exception via mxcsr included). (mix of Doug Ledford, Ingo Molnar, Gabriel Paubert PIII patch for 2.2.x and 2.4.x PIII support from Gareth Hughes, audited, fixed and changed by me to be dynamic. At the end it's very similar to the 2.4.x support) Kernel now understands the `nofxsr' boot time parameter and it doesn't enable fxsr in that case (if there's any CPU that crashes at boot because it's buggy, nofxsr will workaround the hardware bug; it's also useful for asymetric multiprocessing where boot cpu can have fxsr capabilities and the other cpus hasn't) 00_SIGIO-reason-2.bz2 Pass the reason for the sigio in the si_code (and a duplicate info in si_band) with the same API of 2.4.x. This avoids people having to poll a set of fd during the sigio handler. (current 2.4.x has two bugs in that area but fixes are in Linus's mailbox) 00_SMP-scheduler-2.2.18pre21-H.bz2 Better SMP reschedule_idle. (partly backported from 2.3.x, 2.3.x version was contributed by Ingo Molnar) Fixes the wmb() in schedule_tail that should really be a mb(), in theory one of the last reads in reschedule_idle could return garbage (in practice I think it can't trigger... at least on x86 :) (me) 00_VM-locked-1 wait I/O completion as well while doing the Wait_IO second pass on the dirty cache (should fix last VM problem reported by VA while creating very large ext2 fs on lowmem machines) 00_VM_RESERVED-1 Allows device drivers to set the VMA as reserved to avoid swap_out to try to unmap stuff from them (this avoid device drivers using ->nopage for lazily mapping scatter gather dma areas in userspace, to implement a noop swapout and it also avoids useless page faults). This is much more efficient than setting the physical pages as reserved. 00_alpha-epoch-2 Fixes the RTC parsing done by the kernel at boot. (backported from 2.4.x)
Re: LANANA: To Pending Device Number Registrants
According to James Simmons: > Graphics cards are the same way. Especially high end ones. They have pipes > as well. For low end cards you can think of them as single pipeline cards > with one pipe. It still frosts my shorts that DRM (e.g. /dev/dri/card0) doesn't use write(). It's a natural way to feed pipelines. But no, it's a raft of ioctl() calls. *sigh* -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - 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: LANANA: To Pending Device Number Registrants
According to Johannes Erdfelt: > I had always made the assumption that sockets were created because you > couldn't easily map IPv4 semantics onto filesystems. It's unreasonable > to have a file for every possible IP address/port you can communicate > with. I think you're right on both counts, but I'm sure you'll agree that just because some undergrad at Berkeley did something a certain way 20 years ago doesn't mean we have to follow it blindly. :-) IIRC, Plan 9 allocate TCP connections rather like Linux allocates ptys. When we allocate a pty we don't have to say what program we're going to connect to; we allocate it and then use it as we like. Similarly, in Plan 9 you allocate a TCP connection without having to say who you're going to connect to. The main differences between the Plan 9 approach and the socket approach are: 1. Plan 9 connections are filesystem entities (like our ptys) 2. Control is done via read/write on a separate control channel, which is *also* a filesystem entity. USB could use a similar approach. And since each client would allocate a new connection entity for its own use -- even if it's going to connect to a device that someone else is already connected to -- permissions becomes quite simple to manage. Come to think of it, the mechanism I'm describing could address all hotpluggable devices -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.5pre2aa1
Detailed description of 2.4.5pre2aa1 follows. --- 00_alpha-illegal-irq-1 Be verbose for MAX_ILLEGAL_IRQS times if an invalid irq number is getting run. (debugging) 00_alpha-ksyms-1 Export a few alpha-arch symbols needed by modules. (recommended to avoid compilation troubles) 00_alpha-large-vmalloc-1 Drop the CONFIG_LARGE_VMALLOC selection from the arch/alpha/config.in, the large-vmalloc feature is racy and it can destabilize the machine, fixing it isn't worthwhile because nobody needs more than 8Gigabytes of ram in vmalloc memory, not even tux on the 256G boxes will ever need that. (recommended) 00_alpha-modrace-1 Fix alpha races between module insmod/rmmod and the page fault fixmap lookup. (recommended) 00_alpha-numa-10 Fully support wildfire machines with all kind of NUMA memory configuration, plus it optimizes the allocation on per node basis to boost the performance on the NUMA boxes. Right now CONFIG_WILDFIRE needs to be selected to take advantage of this feature. (CONFIG_GENERIC + CONFIG_DISCONTIGMEM=y and CONFIG_NUMA=y will work fine as well but it won't take advantage of the new feature. It also fixes many memory management bit in the core linux allocator in the common code, mostly to avoid wasting static memory. (recommended) 00_alpha-sched-yield-1 Fixes SCHED_YIELD on the alpha arch for UP compiles. (recommended) 00_alpha-show_stack-1 Implements the show_stack() call used often by some common code, mostly to allow compilation, things like tux needs it. (nice to have) 00_alpha-tlb-page-sym-1 Drops a not necessary export on the alpha port. (recommended) 00_buffer-2 Reschedule during oom while allocating buffers, still getblk can deadlock with oom but this will hide it pretty well as it won't loop in a tight loop anymore. (recommended) 00_cachelinealigned-in-smp-1 Moves the pagecache_lock and the VM pagemap_lru_lock in two different L1 cachelines to avoid contention, mostly useful on the alpha where the spinlocks uses load locked store conditional loops (and we don't want to loop). (nice to have) 00_copy-user-lat-2 Put the rechedule points into copy-user calls, with lots of cache large read/writes could otherwise _never_ reschedule once until they returns to userspace. (recommended) 00_cpus_allowed-1 Fixes a bug in the cpu affinity in-kernel API, bug was fatal for ksoftirqd. (recommended) 00_double-buffer-pass-1 Avoids looping two times for no good reason into the lru lists of the buffer cache (the double loop was an unreliable hack from the prehistory that survided 'till today). (nice to have) 00_exception-table-1 Avoids a compilation warning when compiling without modules. (very minor thing) 00_highmem-deadlock-3 Fixes an highmem deadlock using a reserved pool for the bounce buffers. (recommended) 00_highmem-debug-1 Allows people with x86 machines with less than 1G of ram to test the highmem code. (debugging) 00_ia32-bootmem-corruption-1 Fixes the x86 boot stage to finish initializing all the reserved memory before starting allocating memory. (recommended) 00_ipv6-null-oops-1 Fixes null pointer oops. (recommended) 00_jens-loop-noop-nobounce-1 Skips the bounces with the null transfer function. (nice to have) 00_ksoftirqd-4 Avoids 1/HZ latency for the softirq if the softirq is marked again pending when do_softirq() finished and the machine is otherwise idle, it also fixes the case of a softirq re-marking itself runnable by delegating to the scheduler the balance of the softirq load like if it would be an normal task. (nice to have) 00_kupdate-large-interval-1 Allows to set large interval for the kupdate runs, this is useful on the laptops, instead of sigstopping ksoftirqd it's nicer to set a large interval for example of the order of one hour (do that at your own risk of course, doing that is not recommended unless you know what you're doing). (nice to have) 00_lvm-0.9.1_beta7-4 Updates to the lvmbeta7 with fixes for the lv hardsectsize estimantion based on the max hardsectsize of the underlying pv, plus it has some other tons of fixes and it is a must have for the 64bit archs as the IOP silenty changed for those platforms. (recommended) 00_max_readahead-1 Increases the max_readahead to allow
Re: 3c900 card and kernel 2.4.3
Andrew Morton wrote: > > Juri Haberland wrote: > > Do you use 10Base2 (aka cheaper net)? > > I do and after upgrading to 2.4.3 (I think) I had to force the driver to > > use the BNC connector though the card was configured (via the little config > > program supplied by 3com) to always use the BNC connector... > > This way I lost several hours to figure out why it wasn't working anymore and > > to discover that I have to build it as a module instead of having it compiled > > into the kernel because I couldn't make it work with kernel options - only > > with driver options... > > Any suggestions? > For non-modular drivers things are less easy. If you > want to force it to use 10baseT (if_port zero) then > it should work OK if you cheat and use mem_start=0x400. > So `ether=0,0,0x400'. > > For BNC, it should work just fine with `ether=0,0,1'. > If it doesn't, please shout at me. Compile the > driver with `static int vortex_debug = 7;' at line > 183 and send me the boot logs. Hi Andrew, I tried it with 'ether=0,0,1', 3 and also 7, but to no avail. The output of dmesg follows. Thanks, Juri Linux version 2.4.4-xfs ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-81)) #4 Tue May 15 23:17:53 CEST 2001 [--snip--] Kernel command line: auto BOOT_IMAGE=linux ro root=305 BOOT_FILE=/boot/vmlinuz hdc=ide-scsi ether=0,0,3 [--snip--] PCI: Found IRQ 10 for device 00:0f.0 3c59x.c:LK1.1.13 27 Jan 2001 Donald Becker and others. http://www.scyld.com/network/vortex.html See Documentation/networking/vortex.txt eth0: 3Com PCI 3c900 Cyclone 10Mbps Combo at 0xc800, 00:10:5a:d6:84:df, IRQ 10 product code 5050 rev 00.4 date 11-21-98 Internal config register is 180, transceivers 0x38. 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 1809. Enabling bus-master transmits and whole-frame receives. eth0: scatter/gather enabled. h/w checksums enabled [--snip--] spurious 8259A interrupt: IRQ7. eth0: Filling in the Rx ring. eth0: using NWAY device table, not 8 eth0: Initial media type Autonegotiate. vortex_up(): writing 0x180 to InternalConfig eth0: MII #24 status 1809, link partner capability , info1 0010, setting half-duplex. eth0: vortex_up() InternalConfig 0180. eth0: vortex_up() irq 10 media status 8080. boomerang_start_xmit() eth0: Trying to send a packet, Tx index 0. boomerang_interrupt. status=0xe201 eth0: interrupt, status e201, latency 5 ticks. eth0: In interrupt loop, status e201. boomerang_interrupt: wake queue eth0: exiting interrupt, status e000. boomerang_start_xmit() eth0: Trying to send a packet, Tx index 1. boomerang_interrupt. status=0xe201 eth0: interrupt, status e201, latency 5 ticks. eth0: In interrupt loop, status e201. boomerang_interrupt: wake queue eth0: exiting interrupt, status e000. boomerang_start_xmit() eth0: Trying to send a packet, Tx index 2. boomerang_interrupt. status=0xe201 eth0: interrupt, status e201, latency 4 ticks. eth0: In interrupt loop, status e201. boomerang_interrupt: wake queue eth0: exiting interrupt, status e000. eth0: Media selection timer tick happened, Autonegotiate. dev->watchdog_timeo=500 eth0: MII transceiver has status 1809. eth0: Media selection timer finished, Autonegotiate. boomerang_start_xmit() eth0: Trying to send a packet, Tx index 3. boomerang_interrupt. status=0xe201 eth0: interrupt, status e201, latency 5 ticks. eth0: In interrupt loop, status e201. boomerang_interrupt: wake queue eth0: exiting interrupt, status e000. boomerang_start_xmit() eth0: Trying to send a packet, Tx index 4. boomerang_interrupt. status=0xe201 eth0: interrupt, status e201, latency 5 ticks. eth0: In interrupt loop, status e201. boomerang_interrupt: wake queue eth0: exiting interrupt, status e000. boomerang_start_xmit() eth0: Trying to send a packet, Tx index 5. boomerang_interrupt. status=0xe201 eth0: interrupt, status e201, latency 4 ticks. eth0: In interrupt loop, status e201. boomerang_interrupt: wake queue eth0: exiting interrupt, status e000. boomerang_start_xmit() eth0: Trying to send a packet, Tx index 6. boomerang_interrupt. status=0xe201 eth0: interrupt, status e201, latency 6 ticks. eth0: In interrupt loop, status e201. boomerang_interrupt: wake queue eth0: exiting interrupt, status e000. boomerang_start_xmit() eth0: Trying to send a packet, Tx index 7. boomerang_interrupt. status=0xe201 eth0: interrupt, status e201, latency 5 ticks. eth0: In interrupt loop, status e201. boomerang_interrupt: wake queue eth0: exiting interrupt, status e000. boomerang_interrupt. status=0xe081 eth0: interrupt, status e081, latency 4 ticks. eth0: In interrupt loop, status e081. eth0: vortex_error(), status=0xe081 eth0: Updating stats. eth0: exiting interrupt, status e000. boomerang_start_xmit() eth0: Trying to send a packet, Tx index 8. boomerang_interrupt. status=0xe201 eth0: interrupt, status e201, latency 5 ticks. eth0: In interrupt loop, status e201. boomerang_interrupt: wake queue eth0:
Re: LANANA: To Pending Device Number Registrants
Alexander Viro wrote: > > On Tue, 15 May 2001, Chip Salzenberg wrote: > > > According to Linus Torvalds: > > > I don't see why we couldn't expose the "driver name" for any file > > > descriptor. > > > > Is it wise to assume that there is only one such name for *any* file > > descriptor? > > Type of filesystem where the file came from? Sure. > I think this is the wrong question. A device can inherently belong to multiple device classes, and it really should be thought of as such. For example a disk may belong, at the same time, to the "scsi", "disk" and "scsi-disk" device classes, meaning that it supports the union of the "scsi" common interfaces, "disk" common interfaces, and "scsi-disk" common interfaces. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Exporting symbols from a module.
Anders Fugmann writes: > I've got a simple question - how export symbols from one module, and use > them in another. > > I have two modules - 'kvaser' and 'can_master'. > 'kvaser' exports some functions, and 'can_master' needs to use call > these functions. > > I used EXPORT_SYMBOL, and declared the function extern, > but i still get unresolved symbols. > > > insmod kvaser.o > > insmod can_master.o > can_master.o: unresolved symbol can_hw_no_messages > can_master.o: unresolved symbol can_hw_register > can_master.o: unresolved symbol can_hw_get_message > can_master.o: unresolved symbol can_hw_unregister > can_master.o: unresolved symbol can_hw_listen > can_master.o: unresolved symbol can_hw_block > can_master.o: unresolved symbol can_hw_send_message > > > Looking in /proc/ksyms, i can find the exported symbols from the kvaser > driver, but it they are in a different format than all the others. > > d3d27070 can_hw_register_R__ver_can_hw_register [kvaser] > d3d27090 can_hw_unregister_R__ver_can_hw_unregister [kvaser] > d3d270b0 can_hw_listen_R__ver_can_hw_listen [kvaser] > d3d270c4 can_hw_block_R__ver_can_hw_block [kvaser] > d3d270e8 can_hw_send_message_R__ver_can_hw_send_message [kvaser] > d3d270f8 can_hw_get_message_R__ver_can_hw_get_message [kvaser] > d3d27108 can_hw_no_messages_R__ver_can_hw_no_messages [kvaser] > d3d27000 > __insmod_kvaser_O/home/afu/cvs/dtu/49422/canbus/src/kvaser.o_M3B01709C_V132100 I just recently had this problem, and your Makefile is missing: export-objs := .o where .o is the compiled object file from .c, and not the module name (if it is different). Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Tue, May 15, 2001 at 10:29:38PM +0100, Alex Bligh - linux-kernel wrote: > > The argument that "if you use numbering based on where in the SCSI chain > > the disk is, disks don't pop in and out" is absolute crap. It's not true > > even for SCSI any more (there are devices that will aquire their location > > dynamically), and it has never been true anywhere else. Give it up. > > Q: Let us assume you have dynamic numbering disk0..N as you suggest, >and you have some s/w RAID of SCSI disks. A disk fails, and is (hot) >removed. Life continues. You reboot the machine. Disks are now numbered >disk0..(N-1). If the RAID config specifies using disk0..N thusly, it >is going to be very confused, as stripes will appear in the wrong place. >Doesn't that mean the file specifying the RAID config is going to have >to enumerate SCSI IDs (or something configuration invariant) as >opposed to use the disk0..N numbering anyway? Sure it can interrogate >each disk0..N to see which has the ID that it actually wanted, but >doesn't this rather subvert the purpose? > > IE, given one could create /dev/disk/?.+, isn't the important > argument that they share common major device numbers etc., not whether > they linearly reorder precisely to 0..N as opposed to have some form > of identifier guaranteed to be static across reboot & config change. I was think about something along these lines earlier, and I guess this is the perfect time to bring it up.. Before I started working with Linux full time, I did a lot of work as an admin with Digital UNIX/Tru64. Tru64 v5 has a feature that at first glance I wasn't too sure about, but it's sort of grown on me. /dev/disk/* is populated with entries of the style dsk0a, dsk0b, etc.. The numbering of the disk is bus independant, ID independent, even transport independant. The disks are kept track of by disk serial number, and so for example, if you have three disks with serials "456", "123", "789", they would be recognized as dsk0, dsk1, dsk2, in the order of discovery. Once discovered, the disk with a certain serial number will _always_ be at a certain "dsk#" location, stored in /etc/disk-mappings or some such file in the root filesystem. Under the current system, if dsk1 fails, and the system reboots, all the disk numbers slide down. Linus mentioned "of course your disk numbers will change" earlier, but there's no real reason they have to, but there's also no reason you have to access them in the sys-v'ish c0d0p0.. style either. What I liked about the way Tru64 did it is that the disk numbering stays the same. You could've just taken the disk out for a day to put in another system, and you're planning on putting it back in. Re-attach the disk w/ serial number "123", and it gets assigned "dsk1" again. Add another disk to the system, it gets dsk3, regardless of whether dsk1 was re-attached or not. This approach has the advantage of abstracting the device type from the user, as well as offering reproducable ordering. The clear and immediate exception to all of this is replacing a failed disk, RAID or not. Since the mapping is done via user space, a simple utility, or even a text editor could remap a "new" disk to an "old" location, thus making the disk replaced. The "moving" of the disk to a different location shouldn't be much different than a device disappearing and reappearing. Of course, this is all a high level view of the whole process, but I thought I'd throw it out there for comment. -Jeff -- Jeff Mahoney [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
> > Yes. And we also use write to send data to printer. So what? Nobody makes > > you use the same file. > > You're talking about /dev/fb0 vs. /dev/fb0ctl, right? No. We are talking about a fbdev filesystem versus what we have now. See later in the thread. - 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: LANANA: To Pending Device Number Registrants
> > I couldn't agree with you more. It gives me headaches at work. One note, > > their is a except to the eth0 thing. USB to USB networking. It uses usb0, > > etc. I personally which they use eth0. > > USB to USB networking cables aren't ethernet. I'm talking about a wireless connection. ipaq USB cradle to PC. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] SCSI disk minor number cleaning
Andrzej Krzysztofowicz wrote: > > Hi, > The following patch cleans up a bit usage of parameters related to > number of minors per disk in the SCSI subsystem. This is a preliminary > patch and it seems to not contain any problematic changes. The full version > of the patch (that allows to succesfully change SCSI_MINOR_SHIFT and use > more/less partitions per disk) is available at > > ftp://rudy.mif.pg.gda.pl/pub/People/ankry/patches/scsi-minor/ > > Both are against 2.4.4-ac9, but the "shorter" one can be applied to > 2.4.5-pre series as well. > > Any comments are welcome. Good stuff! This is at least tagging where the problems are! - 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: Getting FS access events
On Tue, May 15, 2001 at 02:02:29PM -0700, Linus Torvalds wrote: > In article <[EMAIL PROTECTED]>, > Alexander Viro <[EMAIL PROTECTED]> wrote: > >On Tue, 15 May 2001, H. Peter Anvin wrote: > > > >> Alexander Viro wrote: > >> > > > >> > > None whatsoever. The one thing that matters is that noone starts making > >> > > the assumption that mapping->host->i_mapping == mapping. Don't worry too much about that, that relationship has been false for Coda ever since i_mapping was introduced. The only problem that is still lingering is related to i_size. Writes update inode->i_mapping->host->i_size, and stat reads inode->i_size, which are not the same. I sent a small patch to stat.c for this a long time ago (Linux 2.3.99-pre6-7), which made the assumption in stat that i_mapping->host was an inode. (effectively tmp.st_size = inode->i_mapping->host->i_size) Other solutions were to finish the getattr implementation, or keep a small Coda-specific wrapper for generic_file_write around. > >> > One actually shouldn't assume that mapping->host is an inode. > >> > >> What else could it be, since it's a "struct inode *"? NULL? > > > >struct block_device *, for one thing. We'll have to do that as soon > >as we do block devices in pagecache. > > No, Al. It's an inode. It was a major mistake to ever think anything > else. So is anyone interested in a small patch for stat.c? It fixes, as far as I know, the last place that 'assumes' that inode->i_mapping->host is identical to Jan - 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: CD-RW ide-scsi problem presists with 2.4.4 (was Re: Problem with 2.4.1/2.4.3 and CD-RW ide-scsi drive)
Hi there, in fact I had the same problem with ide-scsi that you mentioned. I also tried the kernel version 2.4.4 but it did not solve the problem. I have a CD-RW drive (/dev/hdd resp. /dev/sr1) that was fully functional even in ide-scsi mode. I also have a CD-ROM drive (/dev/hdb resp. /dev/sr0) that worked perfectly as ide drive but did not work at all in ide-scsi mode. For example, dd if=/dev/sr0 of=/dev/null which should read a CD-ROM in iso9660 format yielded lots of error messages. So I tried to disable the UDMA mode using the hdparm utility hdparm -d 1 -X 34 /dev/hdb which activates 'multiword DMA mode 2'. Now the CD-ROM drive is fully functional (at least for me...) ! You could even try to disable DMA mode completely typing hdparm -d 0 /dev/hdb (e.g.) May be this works around the bug for now. I hope, this is somewhat helpul. Thomas On Wed, Apr 11, 2001 at 10:53:57PM -0400, Tim Meushaw wrote: > Hi there. I just got a new CD-RW drive and am trying to get it working > under Linux. I've got the ide-scsi modules all loaded, but have weird > errors when trying to mount a disk. > > Here are the messages from "dmesg" that I get when the ide-cd and > ide-scsi modules are loaded. My DVD-ROM is /dev/hdc, and the CD-RW is > /dev/hdd (or /dev/sr0): > > - > hdc: ATAPI DVD-ROM drive, 512kB Cache, UDMA(33) > Uniform CD-ROM driver Revision: 3.12 > ide-cd: ignoring drive hdd > scsi0 : SCSI host adapter emulation for IDE ATAPI devices > Vendor: SONY Model: CD-RW CRX160ERev: 1.0e > Type: CD-ROM ANSI SCSI revision: 02 > Detected scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0 > sr0: scsi3-mmc drive: 32x/32x writer cd/rw xa/form2 cdda tray > - > > So, it looks like the drive is attached to /dev/sr0 properly. Then, I > run "cdrecord -scanbus" to make sure: > > - > Cdrecord 1.9 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling > Linux sg driver version: 3.1.17 > Using libscg version 'schily-0.1' > scsibus0: > 0,0,0 0) 'SONY' 'CD-RW CRX160E ' '1.0e' Removable CD-ROM > - > > So, it REALLY looks like it's working. However, here's what I get when > I try to mount an ordinary data CD: > > - > athens:~# mount -t iso9660 /dev/sr0 /cdrw > mount: block device /dev/sr0 is write-protected, mounting read-only > SCSI cdrom error : host 0 channel 0 id 0 lun 0 return code = 2800 > [valid=0] Info fld=0x0, Current sd0b:00: sense key Hardware Error > Additional sense indicates Logical unit communication CRC error (Ultra-DMA/32) > I/O error: dev 0b:00, sector 64 > isofs_read_super: bread failed, dev=0b:00, iso_blknum=16, block=32 > mount: wrong fs type, bad option, bad superblock on /dev/sr0, >or too many mounted file systems > - > > I've tried this with both kernel 2.4.1 and 2.4.3 and have the exact same > error. I've also tried multiple data CDs and have the same messages. > The CD-RW is a Sony CRX-160E, plugged in to an Asus A7V motherboard (the > PCI bus is described by "lspci" as "VIA Technologies, Inc. VT8363/8365 > [KT133/KM133 AGP]"). I'm not sure what other information I can provide, > but I'll be happy to give anything else that might be needed to help fix > this problem. > > Thanks a lot! > Tim -- Thomas Baecker email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
Linus Torvalds <[EMAIL PROTECTED]> [01/05/15 16:28]: > > The "eth0..N" naming is done RIGHT! Nothing to do with the kernel but, one should then argue that the current stuff in /etc/sysconfig/network-scripts is broken for hotplug as placing a new network adapter into your bus will renumber your interfaces causing them to be ifconfig'd wrongly. You'd want to associate the IP configuration stuff with the particular network interface, by MAC address. As for the software-RAID getting messed up, isn't that what volume labels are for? What else in the current distro setups is going to need to change for hotplug? - 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: LANANA: To Pending Device Number Registrants
Linus writes: > And my opinion is that the "hot-plugged" approach works for devices even > if they are soldered down - the "plugging" event just always happens > before the OS is booted, and people just don't unplug it. So we might as > well consider devices to always be hot-pluggable, whether that is actually > physically true or not. Because that will always work, and that way we > don't create any artificial distinctions (and they often really _are_ > artifical: historically soldered-down devices tend to eventually move in a > more hot-pluggable direction, as you point out). Basically, what you describe is the system that AIX has used since day 1. All devices are "discovered" at boot time (even if they are soldered-down), and registered in a database (for Linux that database could be /dev and some text files in /etc)... Every device driver supports hot-plugging. No "static" major or minor numbers per-se (i.e. no HPA needed), but devices are static in the sense of "once a device node is created in /dev, it does not change major/minor numbers until removed", so it is the same device name across reboots. Devices keep a device node in /dev until specifically unconfigured (so sysadmins know a device disappeared) but are seen as "unavailable", and can be permanently removed via "rmdev". Real hot-plug devices on Linux could remove their own device node when removed, I suppose. > This is true to the point that I would not actually think that it is a bad > idea to call /sbin/hotplug when we enumerate the motherboard devices. In > fact, if you look at the current network drivers, this is exactly what > will happen: when we auto-detect the motherboard devices, we _will_ > actually call /sbin/hotplug to tell that we've "inserted" a network > device. Yes, in AIX it is always possible to re-run device detection (cfgmgr) to find new devices (if they do not announce that fact themselves). This would re-traverse all of the system busses (including CPU, memory, motherboard(s), etc) looking for new devices, and each item found spits out either endpoints or children which need further enumeration. It is also possible to only selectively run device detection, so you could, say, ask it to check for new disks only on a specific adapter (important if you have 300 disks on a system). This way you can detect new disks, adapter cards, serial ports, etc. any time after the system is up. All disks are identified as "/dev/hdiskX", (serial ports /dev/ttySX, etc) and if you really need to know more about the location of the device that is stored as part of the device attributes (e.g. physical path to that device, I/O addresses, some device attributes like serial number/MAC/etc). > [ The biggest silliness is this "let's try to make the disks appear in the > same order that the BIOS probes them". Now THAT is really stupid, and it > goes on a lot more than I'd ever like to see. ] Of course, since AIX uses exclusively LVM, it can identify which disk is which no matter where it has moved, so it never had that legacy "I have a DOS partition on C: and D: and I don't want to toast them" issue. Since AIX runs only on proprietary H/W it always can tell you which slot a card is in if you need to identify it (which PCI can do, but ISA can't). Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to Linus Torvalds: > I don't see why we couldn't expose the "driver name" for any file > descriptor. Is it wise to assume that there is only one such name for *any* file descriptor? -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] SCSI disk minor number cleaning
> Hi,
> The following patch cleans up a bit usage of parameters related to
> number of minors per disk in the SCSI subsystem. This is a preliminary
> patch and it seems to not contain any problematic changes. The full version
> of the patch (that allows to succesfully change SCSI_MINOR_SHIFT and use
> more/less partitions per disk) is available at
>
> ftp://rudy.mif.pg.gda.pl/pub/People/ankry/patches/scsi-minor/
>
> Both are against 2.4.4-ac9, but the "shorter" one can be applied to
> 2.4.5-pre series as well.
Oops. The previous putch was buggy (broken #include).
The enclosed in corrected...
> Any comments are welcome.
Andrzej
**
diff -ur linux-2.4.4-ac9/drivers/scsi/sd.c linux-scsi/drivers/scsi/sd.c
--- linux-2.4.4-ac9/drivers/scsi/sd.c Thu May 3 19:29:16 2001
+++ linux-scsi/drivers/scsi/sd.cTue May 15 23:39:12 2001
@@ -67,11 +67,12 @@
#define SD_MAJOR(i) (!(i) ? SCSI_DISK0_MAJOR : SCSI_DISK1_MAJOR-1+(i))
-#define SCSI_DISKS_PER_MAJOR 16
+#define SCSI_MINOR_SHIFT 4
+#define SCSI_DISKS_PER_MAJOR (1 << (8 - SCSI_MINOR_SHIFT))
#define SD_MAJOR_NUMBER(i) SD_MAJOR((i) >> 8)
#define SD_MINOR_NUMBER(i) ((i) & 255)
#define MKDEV_SD_PARTITION(i) MKDEV(SD_MAJOR_NUMBER(i), (i) & 255)
-#define MKDEV_SD(index)MKDEV_SD_PARTITION((index) << 4)
+#define MKDEV_SD(index)MKDEV_SD_PARTITION((index) << SCSI_MINOR_SHIFT)
#define N_USED_SCSI_DISKS (sd_template.dev_max + SCSI_DISKS_PER_MAJOR - 1)
#define N_USED_SD_MAJORS (N_USED_SCSI_DISKS / SCSI_DISKS_PER_MAJOR)
@@ -298,7 +299,7 @@
SCSI_LOG_HLQUEUE(1, printk("Doing sd request, dev = %d, block = %d\n", devm,
block));
dpnt = _disks[dev];
- if (devm >= (sd_template.dev_max << 4) ||
+ if (devm >= (sd_template.dev_max << SCSI_MINOR_SHIFT) ||
!dpnt ||
!dpnt->device->online ||
block + SCpnt->request.nr_sectors > sd[devm].nr_sects) {
@@ -563,8 +564,8 @@
{
SCSI_DISK0_MAJOR, /* Major number */
"sd", /* Major name */
- 4, /* Bits to shift to get real from partition */
- 1 << 4, /* Number of partitions per real */
+ SCSI_MINOR_SHIFT, /* Bits to shift to get real from partition */
+ 1 << SCSI_MINOR_SHIFT, /* Number of partitions per real */
NULL, /* hd struct */
NULL, /* block sizes */
0, /* number */
@@ -951,7 +952,7 @@
* The disk reading code does not allow for reading
* of partial sectors.
*/
- for (m = i << 4; m < ((i + 1) << 4); m++) {
+ for (m = i << SCSI_MINOR_SHIFT; m < ((i + 1) <<
+SCSI_MINOR_SHIFT); m++) {
sd_blocksizes[m] = sector_size;
}
} {
@@ -964,8 +965,11 @@
int hard_sector = sector_size;
int sz = rscsi_disks[i].capacity * (hard_sector/256);
- /* There are 16 minors allocated for each major device */
- for (m = i << 4; m < ((i + 1) << 4); m++) {
+ /*
+* There are 1< 1)
sd_gendisks = kmalloc(N_USED_SD_MAJORS * sizeof(struct gendisk),
GFP_ATOMIC);
@@ -1132,10 +1136,10 @@
SCSI_DISKS_PER_MAJOR * sizeof *sd_gendisks[i].flags);
sd_gendisks[i].major = SD_MAJOR(i);
sd_gendisks[i].major_name = "sd";
- sd_gendisks[i].minor_shift = 4;
- sd_gendisks[i].max_p = 1 << 4;
- sd_gendisks[i].part = sd + (i * SCSI_DISKS_PER_MAJOR << 4);
- sd_gendisks[i].sizes = sd_sizes + (i * SCSI_DISKS_PER_MAJOR << 4);
+ sd_gendisks[i].minor_shift = SCSI_MINOR_SHIFT;
+ sd_gendisks[i].max_p = 1 << SCSI_MINOR_SHIFT;
+ sd_gendisks[i].part = sd + (i * SCSI_DISKS_PER_MAJOR <<
+SCSI_MINOR_SHIFT);
+ sd_gendisks[i].sizes = sd_sizes + (i * SCSI_DISKS_PER_MAJOR <<
+SCSI_MINOR_SHIFT);
sd_gendisks[i].nr_real = 0;
sd_gendisks[i].next = sd_gendisks + i + 1;
sd_gendisks[i].real_devices =
@@ -1191,9 +1195,9 @@
if (!rscsi_disks[i].capacity && rscsi_disks[i].device) {
sd_init_onedisk(i);
if (!rscsi_disks[i].has_part_table) {
- sd_sizes[i << 4] = rscsi_disks[i].capacity;
+ sd_sizes[i << SCSI_MINOR_SHIFT] =
+rscsi_disks[i].capacity;
register_disk(_GENDISK(i), MKDEV_SD(i),
- 1<<4, _fops,
+ 1 << SCSI_MINOR_SHIFT, _fops,
Re: LANANA: To Pending Device Number Registrants
According to Alexander Viro: > On Tue, 15 May 2001, James Simmons wrote: > > I would use write except we use write to draw into the framebuffer. If I > > write to the framebuffer with that data the only thing that will happen is > > I will get pretty colors on my screen. > > Yes. And we also use write to send data to printer. So what? Nobody makes > you use the same file. You're talking about /dev/fb0 vs. /dev/fb0ctl, right? Would that driver authors routinely used such clean designs. PS: No, readers, AFAIK, there is no such thing as /dev/fb0ctl. Yet. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - 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: LANANA: To Pending Device Number Registrants
On Tue, May 15, 2001, James Simmons <[EMAIL PROTECTED]> wrote: > > Personally, I'd really like to see /dev/ttyS0 be the first detected serial > > port on a system, /dev/ttyS1 the second, etc. Currently there are plenty of > > different serial hardware with all their own drivers and /dev entries. For > > embedded systems with serial consoles, and also across architectures, this > > is a pain since the filesystem and namely /dev/inittab has to be adjusted > > for all different types of UARTs. This is not the case for every different > > type of NICs and that's a good thing. > > I couldn't agree with you more. It gives me headaches at work. One note, > their is a except to the eth0 thing. USB to USB networking. It uses usb0, > etc. I personally which they use eth0. USB to USB networking cables aren't ethernet. There are USB to ethernet adapters and they do appear as eth0. JE - 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/
