Re: ext2 filesystem corruptions back from dead? 2.4.0-test11
On Fri, 24 Nov 2000, Alexander Viro wrote: > I don't see any attempts to tag you (or ATA subsystem, for that matter) > in that thread. And thread is hardly bogus... I agree that changes in We agree that the "thread" is valid, trust that point. There was a quick pointed question that present, "Is it an IDE disk?" to paraphase the statement. > drivers/ide/* are very unlikely to be the source of that, but information > of that kind can help to weed out some of the changes in ll_rw_blk.c. What may be even more helpful is when I get arround to making an option, for some outstanding patches for 2.5, that would allow for user-space pattern pushing through the driver that gets properly inserted in to the list/buffer-head to make it pass through the block layer. This kind of testing will allow for nibble level tracing through everything, I hope. Cheers, Andre Hedrick CTO Timpanogas Research Group EVP Linux Development, TRG Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
vm in 2.2.18pre23 - behaving worse
I was busy with other things and did not track 2.2.18pre kernels very carefuly, but now I tried 2.2.18pre23 on Alpha and got an impression that a situation with a virtual memory handling is worse than it was, say, in 2.2.18pre15. I can now see in /var/log/messages entries like "VM: killing process sh" or "VM: killing process emacs" because I was compiling a kernel. This does not happen consistently, predictably, or very often but it does happen and I should not be oom. Nothing else crashes, or leaves any traces in log files, and a machine continues apparently not disturbed, but a process is gone. Applying patches from Andrea and the one from Rik, posted some week ago under "blindingly stupid 2.2 VM bug" subject, does not seem to help very much. Sigh! Am I isolated in this experience? Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: PROBLEM: kernel 2.4.0-test11-ac1 hang with usb-uhci and emu10k1
On Thu, Nov 23, 2000 at 06:06:31PM -0500, Jeff Garzik wrote: > Michael Elkins wrote: > > > > On Thu, Nov 23, 2000 at 05:49:52PM +0100, Georg Acher wrote: > > It hangs in start_uhci(): > > > > /* disable legacy emulation */ > > pci_write_config_word (dev, USBLEGSUP, USBLEGSUP_DEFAULT); > > > > The loop that the call is in gets iterated 5 times. For i < 4, the > > if (!(dev->resource[i].flags & 1)) > > is TRUE, but on i==4, it drops into the bottom of the loop to execute > > check_region() and then pci_write_config_word(), where it hangs. > > It may not make a difference, but that check is flat out wrong. The loop still exhibits the same behavior. /usr/include/linux/ioport.h:#define IORESOURCE_IO 0x0100 /* Resource type */ Definitely a different value, however. > Apply this patch... (untested, you may need to include ioport.h) fyi, ioport.h isn't required. On Thu, Nov 23, 2000 at 03:53:27PM -0800, Linus Torvalds wrote: > Try changing the thing around a bit: make the above place say > > /* disable legacy emulation */ > pci_write_config_word (dev, USBLEGSUP, 0); > > and then AFTER we have successfully done a request_irq() call, we > can enable PCI interrupts with > > /* Enable PIRQ */ > pci_write_config_word (dev, USBLEGSUP, USBLEGSUP_DEFAULT); > > Does that make it happier? Yep! That seems to have fixed it. Added the pci_write_config_word() after the request_irq() in alloc_uhci(). me - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ext2 filesystem corruptions back from dead? 2.4.0-test11
On Thu, 23 Nov 2000, Andre Hedrick wrote: [I wrote] > > ? > > If you have a l-k feed from future - please share. I'm not saying that > > Date: Thu, 23 Nov 2000 04:37:21 -0500 (EST) > > > fs/* is not the source of that stuff, but I sure as hell had not said > > that it is. I simply don't know yet. > > You were pointing out changes to reproduce the effect. Erm... Since then the problem had been reproduced on the patched tree, so we apparently have something else. Behaviour on disk/quota overflow is a separate story - even with fixes for that problem stays. > > > Since there have been not kernel changes to the driver that effect the > > > code since 2.4.0-test5 or test6 and it now randomly shows up after five or > > > six revisions out from the change, and the changes were chipset only. > > > > generic_unplug_device() was changed more or less recently. I doubt that > > it is relevant, but... > > Cool, the issue was that I get tried of people blaming the ATA subsystem > for things that it does not do or has control over. Basically, I kill > bogus threads that try to tag me with an old problem of the past that was > a hardware issue. I don't see any attempts to tag you (or ATA subsystem, for that matter) in that thread. And thread is hardly bogus... I agree that changes in drivers/ide/* are very unlikely to be the source of that, but information of that kind can help to weed out some of the changes in ll_rw_blk.c. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: gcc-2.95.2-51 is buggy
On Fri, 24 Nov 2000, Neil Brown wrote: > Ditto for gcc-2.95.2-13 from Debian (potato). It exhibits the same > bug. > Debian applies a total of 49 patches to gcc and the libraries. > > I am tempted to write a little script which discards the patches one > by one and re-builds and re-tests each time, and leave it going all > night but I'm not sure if I actually will. Not all of them are applied on x86: % cat stamps/02-patch-stamp-*|less bootstrap patches applied. cpp-dos-newlines patches applied. cpp-macro-doc patches applied. gcc-cvs-updates-2220 patches applied. gcc-default-arch patches applied. gcc-empty-struct-init patches applied. gcc-manpage patches applied. gcc-pointer-arith patches applied. gcj-debian-policy patches applied. gcj-vs-iconv patches applied. gpc-2.95 patches applied. gpc-updates patches applied. libg++-update patches applied. libobjc patches applied. libstdc++-bastring patches applied. libstdc++-out-of-mem patches applied. libstdc++-wall3 patches applied. libstdc++-wstring patches applied. reporting patches applied. And only 4 have any chance to be relevant: gcc-cvs-updates-2220, gcc-default-arch, gcc-empty-struct-init. Unfortunately, the first one is ~100Kb worth of changes. Hmmm... After some cleaning the whole thing boils down to 11Kb. And I seriously suspect that relevant bits are in cse.c, loop.c or toplev.c, with the first two being the most likely candidates (all coming from the -cvs-updates-2220)... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre, usb mouse messages
> > usb-uhci.c: interrupt, status 3, frame# 212 > > hub.c: already running port 2 disabled by hub (EMI?), re-enabling... [Greg KH] > The messages are harmless debug messages. Anyone want to whip up a > patch to turn them off (like was recently done for 2.4.0-test)? Is this what you mean? Peter diff -urk.bak 2.2.18-19/drivers/usb/hub.c.bak 2.2.18-19/drivers/usb/hub.c --- 2.2.18-19/drivers/usb/hub.c.bak Fri Nov 3 19:20:45 2000 +++ 2.2.18-19/drivers/usb/hub.c Fri Nov 24 00:29:50 2000 @@ -530,11 +530,8 @@ // be shutdown by the hub, this hack enables them again. // Works at least with mouse driver. if (!(portstatus & USB_PORT_STAT_ENABLE) && - (portstatus & USB_PORT_STAT_CONNECTION) && (dev->children[i])) { - err("already running port %i disabled by hub (EMI?), re-enabling...", - i + 1); + (portstatus & USB_PORT_STAT_CONNECTION) && +(dev->children[i])) usb_hub_port_connect_change(dev, i); - } } if (portstatus & USB_PORT_STAT_SUSPEND) { diff -urk.bak 2.2.18-19/drivers/usb/usb-uhci.c.bak 2.2.18-19/drivers/usb/usb-uhci.c --- 2.2.18-19/drivers/usb/usb-uhci.c.bakFri Nov 3 19:20:46 2000 +++ 2.2.18-19/drivers/usb/usb-uhci.cFri Nov 24 00:21:16 2000 @@ -2538,16 +2538,10 @@ dbg("interrupt"); - if (status != 1) { - warn("interrupt, status %x, frame# %i", status, -UHCI_GET_CURRENT_FRAME(s)); + // remove host controller halted state + if ((status&0x20) && (s->running)) + outw (USBCMD_RS | inw(io_addr + USBCMD), io_addr + USBCMD); - // remove host controller halted state - if ((status&0x20) && (s->running)) { - outw (USBCMD_RS | inw(io_addr + USBCMD), io_addr + USBCMD); - } - //uhci_show_status (s); - } /* * traverse the list in *reverse* direction, because new entries * may be added at the end. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ext2 filesystem corruptions back from dead? 2.4.0-test11
On Fri, 24 Nov 2000, Alexander Viro wrote: > > > On Thu, 23 Nov 2000, Andre Hedrick wrote: > > > What the F*** does that have to do with the price of eggs in china, heh? > > Just maybe if you could follow a thread, you would see that that Alex Viro > > has pointed out that changes in the FS layer as dorked things. > > ? > If you have a l-k feed from future - please share. I'm not saying that Date: Thu, 23 Nov 2000 04:37:21 -0500 (EST) > fs/* is not the source of that stuff, but I sure as hell had not said > that it is. I simply don't know yet. You were pointing out changes to reproduce the effect. > > Since there have been not kernel changes to the driver that effect the > > code since 2.4.0-test5 or test6 and it now randomly shows up after five or > > six revisions out from the change, and the changes were chipset only. > > generic_unplug_device() was changed more or less recently. I doubt that > it is relevant, but... Cool, the issue was that I get tried of people blaming the ATA subsystem for things that it does not do or has control over. Basically, I kill bogus threads that try to tag me with an old problem of the past that was a hardware issue. Given the latest stats that more than 90% of the linux install base is hinged on me getting the low-level engine core correct, I go on benders when cheap shots are take across the bow. Now the only issue that is even on the radar map is a potential 1GB cross copy execution where I have a single report that md5sums do not match. I have yet to reproduce it even with the identical hardware sent to me. I questioned _A_ about this and there may be a case that is OS independent which is more important to me than other. This is a non-fixable for 6->12 months, until I kick some tail in the standards committee meetings over this point. If it is a reality, Linux and Microsoft will join as the OS's represented there and force the change. Only because there are potentical side-bars that NT is effected also in these rare cases. Cheers, Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
lseek patch for 2.2.18pre23
2.2.18pre23 allows lseek to negative offsets in ext2 and has no checks for proc. Here is a patch. BTW, ext2 2.4-test10 is ok. -- H.J. Lu ([EMAIL PROTECTED]) --- --- linux/fs/ext2/file.c.lseek Sat Nov 18 17:18:49 2000 +++ linux/fs/ext2/file.cThu Nov 23 21:54:58 2000 @@ -120,6 +120,8 @@ static long long ext2_file_lseek( case 1: offset += file->f_pos; } + if (offset < 0) + return -EINVAL; if (((unsigned long long) offset >> 32) != 0) { #if BITS_PER_LONG < 64 return -EINVAL; --- linux/fs/proc/mem.c.lseek Tue Jan 4 10:12:23 2000 +++ linux/fs/proc/mem.c Sat Nov 18 17:19:28 2000 @@ -196,14 +196,17 @@ static long long mem_lseek(struct file * { switch (orig) { case 0: - file->f_pos = offset; - return file->f_pos; + break; case 1: - file->f_pos += offset; - return file->f_pos; + offset += file->f_pos; + break; default: return -EINVAL; } + if (offset < 0) + return -EINVAL; + file->f_pos = offset; + return offset; } /* - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ext2 filesystem corruptions back from dead? 2.4.0-test11
On Thu, 23 Nov 2000, Andre Hedrick wrote: > What the F*** does that have to do with the price of eggs in china, heh? > Just maybe if you could follow a thread, you would see that that Alex Viro > has pointed out that changes in the FS layer as dorked things. ? If you have a l-k feed from future - please share. I'm not saying that fs/* is not the source of that stuff, but I sure as hell had not said that it is. I simply don't know yet. > Since there have been not kernel changes to the driver that effect the > code since 2.4.0-test5 or test6 and it now randomly shows up after five or > six revisions out from the change, and the changes were chipset only. generic_unplug_device() was changed more or less recently. I doubt that it is relevant, but... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: gcc 2.95.2 is buggy
[Chris Wedgwood] > taking away -O2 is a 'fix' for now... not a very good one though. Not if you want function inlining to work. The kernel *won't compile* without optimization. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ext2 filesystem corruptions back from dead? 2.4.0-test11
On Thu, 23 Nov 2000, Ion Badulescu wrote: > > Yesterday I had a diff -r showing that the old version > > was corrupted and the new was OK. Of course a second > > look showed that the old version also was OK, the corruption > > must have been in the buffer cache, not on disk.) > > Are these disks IDE disks by any chance? What the F*** does that have to do with the price of eggs in china, heh? Just maybe if you could follow a thread, you would see that that Alex Viro has pointed out that changes in the FS layer as dorked things. Since there have been not kernel changes to the driver that effect the code since 2.4.0-test5 or test6 and it now randomly shows up after five or six revisions out from the change, and the changes were chipset only. Please make your point. Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ext2 filesystem corruptions back from dead? 2.4.0-test11
On Fri, 24 Nov 2000, Mohammad A. Haque wrote: > I got the error while I was compiling XFree86 4 CVS and kernel. So > that's what I've been doing in multiples along witha couple otehr things > thrown inthe mix to generate lots of disk i/o. Error messages would be interesting... So far we have _both_ 2.95 and 2.91 involved, raid and non-raid alike. Just fscking peachy... OK, let's try to eliminate ext2 changes (if that helps we have a big problem somewhere, but that's at least something): patch -p1 -Ri_sb; - inode->i_sb = sb; - inode->i_flags = 0; lock_super (sb); es = sb->u.ext2_sb.s_es; repeat: @@ -430,9 +428,6 @@ mark_buffer_dirty(sb->u.ext2_sb.s_sbh); sb->s_dirt = 1; inode->i_mode = mode; - inode->i_sb = sb; - inode->i_nlink = 1; - inode->i_dev = sb->s_dev; inode->i_uid = current->fsuid; if (test_opt (sb, GRPID)) inode->i_gid = dir->i_gid; EOF Notice that if reverting that change stops the fs corruption we _still_ have a problem - the only case when it could help is if something touches an inode allocated by get_empty_inode() before it gets included into the hash. BTW, folks, while we are looking at the configurations - how about highmem and SMP vs. UP? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: gcc-2.95.2-51 is buggy
On Friday November 24, [EMAIL PROTECTED] wrote: > >> ... RedHat's GCC snapshot "2.96" handles this case just fine. > > > Now, if you can isolate the relevant part of the diff between > > 2.95.2 and RH 2.96... > > Maybe I have to be more precise in the statement "gcc 2.95.2 is buggy". > > I just installed gcc 2.95.2 freshly ftp'ed from ftp.gnu.org, and > ... > > So, not all versions of gcc 2.95.2 are equal. > > % rpm -qf /usr/bin/gcc > gcc-2.95.2-51 > > This is from a SuSE distribution, I forget which, not very recent. > Revised summary: gcc-2.95.2-51 from SuSE is buggy. Ditto for gcc-2.95.2-13 from Debian (potato). It exhibits the same bug. Debian applies a total of 49 patches to gcc and the libraries. I am tempted to write a little script which discards the patches one by one and re-builds and re-tests each time, and leave it going all night but I'm not sure if I actually will. NeilBrown > > Andries > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ext2 filesystem corruptions back from dead? 2.4.0-test11
I got the error while I was compiling XFree86 4 CVS and kernel. So that's what I've been doing in multiples along witha couple otehr things thrown inthe mix to generate lots of disk i/o. Nothing yet, but I'm pretty sure my machine hates me for putting it through this. Alexander Viro wrote: > Bloody interesting. I don't see anything recent that could affect the > areas in question. Intersting versions to check: 11-pre5 and 11-pre6. > It smells like buffer cache corruption, but I don't see anything > relevant. __generic_unplug_device() change loock pretty innocent, > ditto for bh_kmap() ones in raid5 and on ext2 side we had two obviously > equivalent replacements (pre5->pre6). No buffer.c changes, no VM ones. > Urgh. -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ext2 filesystem corruptions back from dead? 2.4.0-test11
Yep. Unless of course they are SCSI with an identity crisis =P Ion Badulescu wrote: > > Are these disks IDE disks by any chance? > > Ion > -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ext2 filesystem corruptions back from dead? 2.4.0-test11
On Fri, 24 Nov 2000, Neil Brown wrote: > I ran my test script, which builds a variety of raid5 arrays with > varying numbers of drives and chunk sizes, and runs mkfs/bonnie/dbench > on each array, and it got through about 8 file systems but choked on > the 9th by trying to allocate lots of blocks in the system zone (after > running for about an hour). Bloody interesting. I don't see anything recent that could affect the areas in question. Intersting versions to check: 11-pre5 and 11-pre6. It smells like buffer cache corruption, but I don't see anything relevant. __generic_unplug_device() change loock pretty innocent, ditto for bh_kmap() ones in raid5 and on ext2 side we had two obviously equivalent replacements (pre5->pre6). No buffer.c changes, no VM ones. Urgh. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ext2 filesystem corruptions back from dead? 2.4.0-test11
On Thu, Nov 23, 2000 at 08:58:39PM -0800, Ion Badulescu wrote: > > (I am reorganizing my disks, copying large trees from > > one place to the other. Always doing a diff -r between > > old and new before removing the old version. > > Yesterday I had a diff -r showing that the old version > > was corrupted and the new was OK. Of course a second > > look showed that the old version also was OK, the corruption > > must have been in the buffer cache, not on disk.) > > Are these disks IDE disks by any chance? Yes. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
gcc-2.95.2-51 is buggy
>> ... RedHat's GCC snapshot "2.96" handles this case just fine. > Now, if you can isolate the relevant part of the diff between > 2.95.2 and RH 2.96... Maybe I have to be more precise in the statement "gcc 2.95.2 is buggy". I just installed gcc 2.95.2 freshly ftp'ed from ftp.gnu.org, and % /usr/bin/gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs gcc version 2.95.2 19991024 (release) % /usr/bin/gcc -Wall -O2 -o bug bug.c; ./bug 0x8480 % /usr/gcc/aeb/bin/gcc -v Reading specs from /usr/gcc/aeb/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs gcc version 2.95.2 19991024 (release) % /usr/gcc/aeb/bin/gcc -Wall -O2 -o nobug bug.c; ./nobug 0x0 So, not all versions of gcc 2.95.2 are equal. % rpm -qf /usr/bin/gcc gcc-2.95.2-51 This is from a SuSE distribution, I forget which, not very recent. Revised summary: gcc-2.95.2-51 from SuSE is buggy. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NFSD dentry manipulation (was Re: d_move())
According to Neil Brown: > You suggest that d_move (or it's caller) must be able to deal with > the [second parameter] being an "root" dentry (x->d_parent == x). > However, I cannot see that this could possibly happen. Hmph. It seems you're right; my d_move changes [1][2] were apparently not required after all. However... The sum of my recent NFS patches incontrovertably turned a totally unstable server into the very model of stability. Why? Let's assume that d_move was a red herring. What else in the old code could have cause dentry bugs? My first thought on that is that the old code (1) created multiple disconnected dentries for a given inode, and yet (2) assumed that multiple disconnected dentries would never be found. I invite others' opinions. And I've included a copy of my recent patches (less d_move) below. [1] I still think it would be reasonable for d_move() to handle root dentries, or at least oops on them for debugging. [2] One bit of the d_splice patches is unrelated to d_move, namely, the move of 'dput(tdentry)' to the bottom of d_splice, allowing the 'parent' flag manipulation to finish before calling dput(), which can sleep. But knfsd uses the big kernel lock, so I guess that's probably no issue either. Index: fs/nfsd/nfsfh.c --- fs/nfsd/nfsfh.c.prev +++ fs/nfsd/nfsfh.c Mon Nov 20 22:31:52 2000 @@ -108,4 +108,15 @@ static int get_ino_name(struct dentry *d } + if (!error) { + /* +* Check for a fs-specific hash function. Note that we must +* calculate the standard hash first, as the d_op->d_hash() +* routine may choose to leave the hash value unchanged. +*/ + name->hash = full_name_hash(name->name, name->len); + if (dentry->d_op && dentry->d_op->d_hash) + error = dentry->d_op->d_hash(dentry, name); + } + out_close: if (file.f_op->release) @@ -115,4 +126,35 @@ out: } +/* Arrange a dentry for the given inode: + * 1. Prefer an existing connected dentry. + * 2. Settle for an existing disconnected dentry. + * 3. If necessary, create a (disconnected) dentry. + */ +static struct dentry *nfsd_arrange_dentry(struct inode *inode) +{ + struct list_head *lp; + struct dentry *result; + + result = NULL; + for (lp = inode->i_dentry.next; lp != >i_dentry ; lp=lp->next) { + result = list_entry(lp,struct dentry, d_alias); + if (! (result->d_flags & DCACHE_NFSD_DISCONNECTED)) + break; + } + if (result) { + dget(result); + iput(inode); + } else { + result = d_alloc_root(inode, NULL); + if (!result) { + iput(inode); + return ERR_PTR(-ENOMEM); + } + result->d_flags |= DCACHE_NFSD_DISCONNECTED; + d_rehash(result); /* so a dput won't loose it */ + } + return result; +} + /* this should be provided by each filesystem in an nfsd_operations interface; * iget isn't really the right interface @@ -121,6 +163,4 @@ static struct dentry *nfsd_iget(struct s { struct inode *inode; - struct list_head *lp; - struct dentry *result; inode = iget(sb, ino); @@ -149,23 +189,6 @@ static struct dentry *nfsd_iget(struct s return ERR_PTR(-ESTALE); } - /* now to find a dentry. -* If possible, get a well-connected one -*/ - for (lp = inode->i_dentry.next; lp != >i_dentry ; lp=lp->next) { - result = list_entry(lp,struct dentry, d_alias); - if (! (result->d_flags & DCACHE_NFSD_DISCONNECTED)) { - dget(result); - iput(inode); - return result; - } - } - result = d_alloc_root(inode, NULL); - if (result == NULL) { - iput(inode); - return ERR_PTR(-ENOMEM); - } - result->d_flags |= DCACHE_NFSD_DISCONNECTED; - d_rehash(result); /* so a dput won't loose it */ - return result; + + return nfsd_arrange_dentry(inode); } @@ -228,43 +245,21 @@ int d_splice(struct dentry *target, stru struct dentry *nfsd_findparent(struct dentry *child) { - struct dentry *tdentry, *pdentry; - tdentry = d_alloc(child, &(const struct qstr) {"..", 2, 0}); - if (!tdentry) + struct dentry *dotdot, *parent; + + dotdot = d_alloc(child, &(const struct qstr) {"..", 2, 0}); + if (!dotdot) return ERR_PTR(-ENOMEM); + parent = child->d_inode->i_op->lookup(child->d_inode, dotdot); + d_drop(dotdot); /* we never want ".." hashed */ - /* I'm going to assume that if the returned dentry is different, then -* it is well connected. But nobody returns different dentrys do they? -*/ - pdentry =
Re: ext2 filesystem corruptions back from dead? 2.4.0-test11
On Thu, 23 Nov 2000 13:52:52 +0100, Guest section DW <[EMAIL PROTECTED]> wrote: > On Thu, Nov 23, 2000 at 05:03:00PM +1100, Neil Brown wrote: > >> Oh, good. It's not just me and Tigran then. > > You have it all backwards. It would be good if it were > just you and Tigran. Unfortunately it also hits me. > > (I am reorganizing my disks, copying large trees from > one place to the other. Always doing a diff -r between > old and new before removing the old version. > Yesterday I had a diff -r showing that the old version > was corrupted and the new was OK. Of course a second > look showed that the old version also was OK, the corruption > must have been in the buffer cache, not on disk.) Are these disks IDE disks by any chance? Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: gcc 2.95.2 is buggy
On Thu, 23 Nov 2000, Gregory Maxwell wrote: > On Fri, Nov 24, 2000 at 02:57:45AM +0100, [EMAIL PROTECTED] wrote: > > but in the meantime there is good confirmation. > > This really is a bug in gcc 2.95.2. > > ... RedHat's GCC snapshot "2.96" handles this case just fine. Now, if you can isolate the relevant part of the diff between 2.95.2 and RH 2.96... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: More PCI ID's for linux-2.4.0-test11/include/linux/pci_ids.h
[Adam J. Richter] > +#define PCI_VENDOR_ID_ELSA 0x1048 > +#define PCI_DEVICE_ID_ELSA_MIRCOLINK 0x1000 > +#define PCI_DEVICE_ID_ELSA_QS30000x3000 Oh, don't propagate the typo. Spell it MICROLINK here and in hisax/elsa.c. > #define PCI_VENDOR_ID_PLX0x10b5 > +#define PCI_DEVICE_ID_SATSAGEM_NICCY 0x1016 > +#define PCI_DEVICE_ID_PLX_R685 0x1030 SATSAGEM_NICCY is misplaced. > @@ -561,15 +568,20 @@ > #define PCI_DEVICE_ID_WINBOND_83769 0x0001 > #define PCI_DEVICE_ID_WINBOND_82C105 0x0105 > #define PCI_DEVICE_ID_WINBOND_83C553 0x0565 > +#define PCI_DEVICE_ID_WINBOND_6692 0x6692 This one needs to go under PCI_VENDOR_ID_WINBOND2 (and hisax/w6692.c should be changed accordingly). Here is my pending pci_ids.h patch, with your changes merged in. (It is longer than it needs to be, thanks to some space->tab conversions.) Peter --- include/linux/pci_ids.h.bak Mon Nov 13 01:43:49 2000 +++ include/linux/pci_ids.h Thu Nov 23 22:33:55 2000 @@ -119,6 +119,10 @@ /* Vendors and devices. Sort key: vendor first, device next. */ +/* Should be Dynalink - same company? */ +#define PCI_VENDOR_ID_ASUSCOM 0x0675 +#define PCI_DEVICE_ID_ASUSCOM_TA1 0x1702 + #define PCI_VENDOR_ID_COMPAQ 0x0e11 #define PCI_DEVICE_ID_COMPAQ_TOKENRING 0x0508 #define PCI_DEVICE_ID_COMPAQ_1280 0x3033 @@ -191,8 +195,8 @@ #define PCI_VENDOR_ID_NS 0x100b #define PCI_DEVICE_ID_NS_87415 0x0002 -#define PCI_DEVICE_ID_NS_87560_LIO 0x000e -#define PCI_DEVICE_ID_NS_87560_USB 0x0012 +#define PCI_DEVICE_ID_NS_87560_LIO 0x000e +#define PCI_DEVICE_ID_NS_87560_USB 0x0012 #define PCI_DEVICE_ID_NS_87410 0xd001 #define PCI_VENDOR_ID_TSENG0x100c @@ -254,9 +258,17 @@ #definePCI_DEVICE_ID_IBM_405GP 0x0156 #define PCI_DEVICE_ID_IBM_MPIC_2 0x +#define PCI_VENDOR_ID_COMPEX2 0x101a // pci.ids says "AT GIS (NCR)" +#define PCI_DEVICE_ID_COMPEX2_100VG0x0005 + #define PCI_VENDOR_ID_WD 0x101c #define PCI_DEVICE_ID_WD_7197 0x3296 +#define PCI_VENDOR_ID_AMI 0x101e +#define PCI_DEVICE_ID_AMI_MEGARAID30x1960 +#define PCI_DEVICE_ID_AMI_MEGARAID 0x9010 +#define PCI_DEVICE_ID_AMI_MEGARAID20x9060 + #define PCI_VENDOR_ID_AMD 0x1022 #define PCI_DEVICE_ID_AMD_LANCE0x2000 #define PCI_DEVICE_ID_AMD_LANCE_HOME 0x2001 @@ -272,6 +284,8 @@ #define PCI_DEVICE_ID_AMD_VIPER_740C 0x740C #define PCI_VENDOR_ID_TRIDENT 0x1023 +#define PCI_DEVICE_ID_TRIDENT_4DWAVE_DX0x2000 +#define PCI_DEVICE_ID_TRIDENT_4DWAVE_NX0x2001 #define PCI_DEVICE_ID_TRIDENT_9320 0x9320 #define PCI_DEVICE_ID_TRIDENT_9388 0x9388 #define PCI_DEVICE_ID_TRIDENT_9397 0x9397 @@ -298,10 +312,10 @@ #define PCI_DEVICE_ID_MATROX_MIL_2 0x051b #define PCI_DEVICE_ID_MATROX_MIL_2_AGP 0x051f #define PCI_DEVICE_ID_MATROX_MGA_IMP 0x0d10 -#define PCI_DEVICE_ID_MATROX_G100_MM0x1000 -#define PCI_DEVICE_ID_MATROX_G100_AGP 0x1001 -#define PCI_DEVICE_ID_MATROX_G200_PCI 0x0520 -#define PCI_DEVICE_ID_MATROX_G200_AGP 0x0521 +#define PCI_DEVICE_ID_MATROX_G100_MM 0x1000 +#define PCI_DEVICE_ID_MATROX_G100_AGP 0x1001 +#define PCI_DEVICE_ID_MATROX_G200_PCI 0x0520 +#define PCI_DEVICE_ID_MATROX_G200_AGP 0x0521 #definePCI_DEVICE_ID_MATROX_G400 0x0525 #define PCI_DEVICE_ID_MATROX_VIA 0x4536 @@ -365,8 +379,8 @@ #define PCI_DEVICE_ID_PCTECH_SAMURAI_1 0x3010 #define PCI_DEVICE_ID_PCTECH_SAMURAI_IDE 0x3020 -#define PCI_VENDOR_ID_DPT 0x1044 -#define PCI_DEVICE_ID_DPT 0xa400 +#define PCI_VENDOR_ID_DPT 0x1044 +#define PCI_DEVICE_ID_DPT 0xa400 #define PCI_VENDOR_ID_OPTI 0x1045 #define PCI_DEVICE_ID_OPTI_92C178 0xc178 @@ -380,6 +394,10 @@ #define PCI_DEVICE_ID_OPTI_82C861 0xc861 #define PCI_DEVICE_ID_OPTI_82C825 0xd568 +#define PCI_VENDOR_ID_ELSA 0x1048 +#define PCI_DEVICE_ID_ELSA_MICROLINK 0x1000 +#define PCI_DEVICE_ID_ELSA_QS3000 0x3000 + #define PCI_VENDOR_ID_SGS 0x104a #define PCI_DEVICE_ID_SGS_2000 0x0008 #define PCI_DEVICE_ID_SGS_1764 0x0009 @@ -406,6 +424,8 @@ #define PCI_DEVICE_ID_TI_1251B 0xac1f #define PCI_DEVICE_ID_TI_1420 0xac51 +#define PCI_VENDOR_ID_SONY 0x104d +#define PCI_DEVICE_ID_SONY_CXD3222 0x8039 #define PCI_VENDOR_ID_OAK 0x104e #define PCI_DEVICE_ID_OAK_OTI107 0x0107 @@ -414,6 +434,7 @@ #define PCI_VENDOR_ID_WINBOND2 0x1050 #define PCI_DEVICE_ID_WINBOND2_89C940 0x0940 #define PCI_DEVICE_ID_WINBOND2_89C940F 0x5a5a +#define PCI_DEVICE_ID_WINBOND2_66920x6692 #define PCI_VENDOR_ID_EFAR 0x1055 #define PCI_DEVICE_ID_EFAR_SLC90E66_1 0x9130 @@ -503,9 +524,10 @@ #define PCI_VENDOR_ID_LEADTEK 0x107d #define PCI_DEVICE_ID_LEADTEK_805
Re: gcc 2.95.2 is buggy
On Fri, Nov 24, 2000 at 02:57:45AM +0100, [EMAIL PROTECTED] wrote: > but in the meantime there is good confirmation. > This really is a bug in gcc 2.95.2. ... RedHat's GCC snapshot "2.96" handles this case just fine. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
ohci1394 PCI device ID's
Sorry for the rather lengthy email list. I am not sure exactly which of you it would be appropriate to put this question to. I am writing a pci_device_id table for ohci1394.c. This will allow a userland program to automatically load the module when an ohci1394 card is present. There is a PCI device class for ohci1394 controllers (pci_dev->class == 0x0c0310). So, is there some reason why linux-2.4.0-test11/drivers/ieee1394/ohci1934.c contains a list of vendor_id/device_id pairs? If ohci1394.c really needs to match based on vendor_id and device_id, then I will generate a pci_device_id table accordingly. On the other hand, if ohci1394.c really does not need to care about vendor_id/device_id pairs, I will add the generic pci_device_id table for an ohci1394 controller, and I would also be happy to generate a patch for you folks that eliminates the use of the vendor_id / device_id pairs, and, if you want, ports the driver to the new hotplug PCI interface, which might be useful, considering that I see ieee1394 CardBus cards everywhere. Any feedback would be appreciated. Thanks in advance. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
More info about de USB HP 8230e and problems]
I have using the next software: a) test11 + storage checkout from linux-usb at sourceforge ( without this checkout fails too). b) cdrecord 1.10a6 If I start to burn a CD at x4 speed, I have always the next error from cdrecord: Track 01: 102 of 109 MB written (fifo 100%)./opt/schily/bin/cdrecord: Input/output error. write_g1: scsi sendcmd: retryable error CDB: 2A 00 00 00 CD 03 00 00 1F 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 03 00 00 00 00 12 00 00 00 00 0C 09 00 00 Sense Key: 0x3 Medium Error, Segment 0 Sense Code: 0x0C Qual 0x09 (write error - loss of streaming) Fru 0x0 Sense flags: Blk 0 (not valid) Well the size of track varies in function that have buring. With the storage-usb debug active I have the next log: usb-storage: Command WRITE_10 (10 bytes) usb-storage: 2a 00 00 00 cd 03 00 00 1f 00 ff bf usb-storage: Transferred out 38 of 38 bytes usb-storage: Transferred out 32768 of 32768 bytes usb-storage: Transferred out 30720 of 30720 bytes usb-storage: -- transport indicates command failure usb-storage: Issuing auto-REQUEST_SENSE usb-storage: Transferred out 14 of 14 bytes usb-storage: Waited not busy for 0 steps usb-storage: Transferred out 12 of 12 bytes usb-storage: Waited not busy for 2 steps usb-storage: Transferred in 18 of 18 bytes usb-storage: 70 00 03 00 00 00 00 12 00 00 00 00 0C 09 00 00 usb-storage: 00 00 usb-storage: -- Result from auto-sense is 0 usb-storage: -- code: 0x70, key: 0x3, ASC: 0xc, ASCQ: 0x9 usb-storage: Medium Error: (unknown ASC/ASCQ) usb-storage: scsi cmd done, result=0x2 usb-storage: *** thread sleeping. usb-storage: queuecommand() called Thesis a i810 based computer. If I burning the CD with the same software at x2 speed with these computer I have no problem burning the CD. But, if I test the CDRW in a laptop with a VIA chipset, I can burn nothing nor x1 speed :(. The chipset of the laptop have I VT82C586B as USB device. The kernel here it's test10. Saludos Drizzt -- ... Los viejos ecologistas nunca mueren, simplemente son reciclados. Drizzt Do'UrdenThree rings for the Elves Kings under the Sky [EMAIL PROTECTED] Seven for the Dwarf_lords in their hall of stone Nine for the Mortal Men doomed to die - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] for ReiserFS 3.5.27 on 2.2.18pre23
For those of you who may want to run ReiserFS on 2.2.18pre23 using reiserfs-3.5.27, you may find as I did that the main reiserfs patch, linux-2.2.17-reiserfs-3.5.27-patch, fails like this: patching file linux/include/linux/fs.h Hunk #1 FAILED at 279. Hunk #2 FAILED at 393. Hunk #3 FAILED at 516. Hunk #4 FAILED at 560. 4 out of 4 hunks FAILED -- saving rejects to file linux/include/linux/fs.h.rej Here is a temporary fix. The following will patch linux/include/linux/fs.h correctly. I am currently running 2.2.18pre23 with reiserfs 3.5.27 using this patch: diff -u linux/include/linux/fs.h.orig linux/include/linux/fs.h --- linux/include/linux/fs.h.orig Thu Nov 23 18:25:10 2000 +++ linux/include/linux/fs.hThu Nov 23 18:38:15 2000 @@ -280,6 +280,7 @@ #include #include #include +#include /* * Attribute flags. These should be or-ed together to figure out what @@ -395,6 +396,7 @@ struct adfs_inode_info adfs_i; struct qnx4_inode_info qnx4_i; struct usbdev_inode_infousbdev_i; + struct reiserfs_inode_info reiserfs_i; struct socket socket_i; void*generic_ip; } u; @@ -520,6 +522,7 @@ #include #include #include +#include extern struct list_head super_blocks; @@ -564,6 +567,7 @@ struct adfs_sb_info adfs_sb; struct qnx4_sb_info qnx4_sb; struct usbdev_sb_info usbdevfs_sb; + struct reiserfs_sb_info reiserfs_sb; void*generic_sbp; } u; /* - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: Modularize /proc/partitons (was Re: /proc/partitions for LVM)
[Brian Kress] > 1) Add a function pointer to struct gendisk called hd_name. > > 2) Make disk_name in fs/partitions/check.c use that function > pointer if its non-null. > > 3) Change the following drivers to use this method. (adding the > driver specific method and removing the old code in check.c) Looks good to me ... except that cpqarray.c, cciss.c and DAC960.c have basically duplicate functions. Would this be a net win: char *typical_disk_name(struct gendisk *, int major_base, int minor, char *buf); ...exported from check.c? Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha SMP problem
On Tue, Nov 07, 2000 at 10:57:49PM -0800, Richard Henderson wrote: > On Tue, Nov 07, 2000 at 10:09:34AM -0800, Reto Baettig wrote: > > I have a problem whith Alpha SMP's which seems to be kernel-related. I > > discussed this on the bug-glibc list but everybody seems to agree that > > it cannot be a libc problem. > > Indeed it does seem to be some sort of tlb flushing problem, Yes it was. > but I've been unable to figure out exactly what. There were a few SMP races that could trigger only using threads: 1) flush_tlb_other could happen after we read the mm->context and we could miss a tlb flush 2) flush_tlb_current could bump up the asn of the current cpu and in turn change the asn version after we acquired a new context leading to an alias between our asn and a later one 3) a PAL_swpctx can't be done in the middle of alpha_switch_to ppc/sparc64 may have similar issues and I didn't checked them (from a fast read it looks like sparc64 is just safe but I don't know the sparc hardware well enough to be sure). I also noticed the horrible implementation of ASN in SMP so while I was there I rewrote it. The rewrote is based on the fact that mm->context makes no sense. It must be an array of mm->context[NR_CPUS]. Almost certainly mips wants an array of NR_CPUS too. Anyways for mips it's not a big deal since SMP isn't supported in 2.2.x ;). In 2.2.x I added: #ifdef __alpha__ in the mm.h code, so that people can apply this patch kernel without breaking compiles of all other architectures. For 2.4.x I'd like to know what sparc64 and ppc wants as mm->context, alpha definitely wants a per-CPU array (probably mips too). With a single mm->context with threads both cpus was going to overwrite the same field at the same time. This just made mm->context useless and it leads to overflow of asn even if there's only 1 MM running in the system. And the old implementation wasn't only bad for threads but it was bad also for regular processes. Every time a task was changing CPU an ASN was wasted. After 512 changes of CPU of the same task the tlb was flushed on both cpus even if there was only 1 or two programs running. With this new design up to 256 different MM (they could belong to 10 threads each or to a single task each) can run in a SMP system without generating any tlb flush (aka ASN overflow) in any CPU regardless of the MM migration between cpus or of the context switches between task and threads. --- 2.2.18pre21aa2/arch/alpha/kernel/smp.c.~1~ Wed Nov 22 02:32:53 2000 +++ 2.2.18pre21aa2/arch/alpha/kernel/smp.c Thu Nov 23 04:48:24 2000 @@ -95,8 +95,7 @@ smp_store_cpu_info(int cpuid) { cpu_data[cpuid].loops_per_jiffy = loops_per_jiffy; - cpu_data[cpuid].last_asn - = (cpuid << WIDTH_HARDWARE_ASN) + ASN_FIRST_VERSION; + cpu_data[cpuid].last_asn = ASN_FIRST_VERSION; cpu_data[cpuid].irq_count = 0; cpu_data[cpuid].bh_count = 0; @@ -905,6 +904,8 @@ struct mm_struct *mm = (struct mm_struct *) x; if (mm == current->mm) flush_tlb_current(mm); + else + flush_tlb_other(mm); } void @@ -912,10 +913,17 @@ { if (mm == current->mm) { flush_tlb_current(mm); - if (atomic_read(>count) == 1) + if (atomic_read(>count) == 1) { + int i, cpu, this_cpu = smp_processor_id(); + for (i = 0; i < smp_num_cpus; i++) { + cpu = cpu_logical_map(i); + if (cpu == this_cpu) + continue; + mm->context[cpu] = 0; + } return; - } else - flush_tlb_other(mm); + } + } if (smp_call_function(ipi_flush_tlb_mm, mm, 1, 1)) { printk(KERN_CRIT "flush_tlb_mm: timed out\n"); @@ -932,8 +940,12 @@ ipi_flush_tlb_page(void *x) { struct flush_tlb_page_struct *data = (struct flush_tlb_page_struct *)x; - if (data->mm == current->mm) - flush_tlb_current_page(data->mm, data->vma, data->addr); + struct mm_struct * mm = data->mm; + + if (mm == current->mm) + flush_tlb_current_page(mm, data->vma, data->addr); + else + flush_tlb_other(mm); } void @@ -944,10 +956,17 @@ if (mm == current->mm) { flush_tlb_current_page(mm, vma, addr); - if (atomic_read(>mm->count) == 1) + if (atomic_read(>mm->count) == 1) { + int i, cpu, this_cpu = smp_processor_id(); + for (i = 0; i < smp_num_cpus; i++) { + cpu = cpu_logical_map(i); + if (cpu == this_cpu) + continue; + mm->context[cpu] = 0; + }
Re: beware of dead string constants
[Jeff Garzik] > If you mean preferring 'if ()' over 'ifdef'... Linus. :) And I agree > with him: code looks -much- more clean without ifdefs. And the > compiler should be smart enough to completely eliminate code inside > an 'if (0)' code block. Plus the advantage/disadvantage of making the compiler parse almost everything, which should eliminate syntax errors, variable name misspellings, etc in little-used config options. The disadvantage is that compilation speed goes down. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
imsttfb.c PCI ID's?
In writing a pci_device_id table for linux-2.4.0-test11/drivers/video/imsttfb.c, I see that that driver theoretically attepts to bind to any PCI video display with a vendor ID set to PCI_VENDOR_ID_IMS, although the code does mention device ID's 0x9128 and 0x9135. Does anybody know if there are other device ID's besides 0x9128 and 0x9135 that imsttfb.c is interested in, or is it OK to write the pci_device_id table to just specify those two rather than all PCI video cards made by IMS? Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ext2 filesystem corruptions back from dead? 2.4.0-test11
On Thursday November 23, [EMAIL PROTECTED] wrote: > > > On Thu, 23 Nov 2000, Alexander Viro wrote: > > > On Thu, 23 Nov 2000, Neil Brown wrote: > > > > > which enabled ext2_notify_change, however ext2_notify_change has a > > > bug. > > > It sets attributes from iattr->ia_attr_flags even > > > if ATTR_ATTR_FLAG is NOT SET in iattr->ia_valid. > > > > Arrrgh. Could you try that: > > OK, I really need more coffee - wrong patch. My apologies. Correct (OK, > intended) one follows: Hmmm. either you need more coffee, or I need a new compiler. I'm using 2.95.2, and there seems to be some question marks over that. Unfortunately debian/potato doesn't seem to offer anything else (Except 2.7.2), so I'll try to download and compile egcs-1.1.2 and see how that works. I ran my test script, which builds a variety of raid5 arrays with varying numbers of drives and chunk sizes, and runs mkfs/bonnie/dbench on each array, and it got through about 8 file systems but choked on the 9th by trying to allocate lots of blocks in the system zone (after running for about an hour). NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2.18: d_move() with self-root dentries (Dentry Corruption!)
On Tuesday November 21, [EMAIL PROTECTED] wrote: > This may be 2.2.18 material after all I wrote last night: > > Making nfsd's d_splice() compensate for d_move's limitations is not > > only a kludge, but also it harder to keep nfsd correct. > > someday, nfsd may not be the only creator of this kind of dentry. > > Sure enough, there is just such a bug *already* in nfsd. Nfsd's > cleanup after d_move is incomplete: It handles one of the dentries > being parentless, but not the other one. This bug *will* cause dentry > corruption.[1] It may well be what's been causing the hangs that my > recent patches seem to have fixed. > > Therefore, in the mainline kernel, we need either the below patch to > d_move (along with a trivial simplifcation of nfsd's use of it), or an > expansion of the kludge in nfsd. You can guess which one I favor > > [1] The bug can only show up when reconstructing pruned dentries, and > only under a specific pattern of client requests, so it's not > surprising that it is rarely observed in the wild. Hi Chip, I am trying to understand what might be going on and why this fix might be needed, and I'm not making much progress. You suggest that d_move (or it's caller) must be able to deal with the target being an "root" dentry (x->d_parent == x). However I cannot see that this could possibly happen. (looking at 2.2.18pre21 which should be much the same as any othe 2.2 knfsd..) The only place that knfsd calls d_move is in d_splice. Here the "dentry" argument is "target" (just to confuse the innocent) and this is almost certainly an "root" entry passed in from "splice". However the "target" argument is "tdentry" which was just created with d_alloc which has given a parent which is certainly non-NULL, otherwise we would have an oops much earlier. So the parent of the "target" is "parent", which is certainly different from "tdentry", so d_move is *not* being asked to move something onto a "root" dentry, so the change is not needed. Did I miss something in the above, or can you in some other way convince me that d_move needs to handle is_root targets. Thanks, NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
gcc 2.95.2 is buggy
Yesterday night I wrote > Note: this is not yet a confirmed compiler bug but in the meantime there is good confirmation. This really is a bug in gcc 2.95.2. >From [EMAIL PROTECTED] Thu Nov 23 10:45:07 2000 > Please, could you send me ... >From [EMAIL PROTECTED] Thu Nov 23 18:00:48 2000 > Can we get a show of hands? Below a demo program. Andries bug.c - /* * bug.c - aeb, 001124 * * This program shows a bug in gcc 2.95.2. * It should print 0x0 and exit. * For me it prints 0x8480. * * Compile with: *gcc -Wall -O2 -o bug bug.c */ #include struct inode { long long i_size; struct super_block *i_sb; }; struct file { long long f_pos; }; struct super_block { int s_blocksize; unsigned char s_blocksize_bits; int s_hs; }; static char * isofs_bread(unsigned int block) { printf("0x%x\n", block); exit(0); } static int do_isofs_readdir(struct inode *inode, struct file *filp) { int bufsize = inode->i_sb->s_blocksize; unsigned char bufbits = inode->i_sb->s_blocksize_bits; unsigned int block, offset; char *bh = NULL; int hs; if (filp->f_pos >= inode->i_size) return 0; offset = filp->f_pos & (bufsize - 1); block = filp->f_pos >> bufbits; hs = inode->i_sb->s_hs; while (filp->f_pos < inode->i_size) { if (!bh) bh = isofs_bread(block); hs += block << bufbits; if (hs == 0) filp->f_pos++; if (offset >= bufsize) offset &= bufsize - 1; if (*bh) filp->f_pos++; filp->f_pos++; } return 0; } struct super_block s; struct inode i; struct file f; int main(int argc, char **argv){ s.s_blocksize = 512; s.s_blocksize_bits = 9; i.i_size = 2048; i.i_sb = f.f_pos = 0; do_isofs_readdir(,); return 0; } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kernel_thread bogosity
On Thu, Nov 23, 2000 at 11:23:33PM +0100, Pavel Machek wrote: > Hi! > > You see? Kernel_thread does not check is sys_clone() worked! Aha, "=" (retval) > caller is responsible for that, but init/main.c does not seem too > carefull. Maybe kernel_thread should at least print a warning? If clone fails during start_kernel that's the last of your problems so nobody cared. If you want to add a check on the retval go ahead, that's right indeed. > Plus, can someone explain me why it does not need to setup %%ecx with > either zero or address of stack? Not necessary because a kernel thread never exit from kernel. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 3c59x: Using bad IRQ 0
Linus Torvalds wrote: > > On Thu, 23 Nov 2000, Tobias Ringstrom wrote: > > > > > > - enable DEBUG in arch/i386/kernel/pci-i386.h. This should make the code > > >print out what the pirq table entries are etc. > > > > Done. When adding the call to eisa_set_level_irq, the line > > > > IRQ for 00:0a.0(0) via 00:0a.0 -> PIRQ 03, mask 1eb8, excl -> newirq=9 -> >assigning IRQ 9 ... OK > > > > was changed into > > > > IRQ for 00:0a.0(0) via 00:0a.0 -> PIRQ 03, mask 1eb8, excl -> newirq=9 -> >assigning IRQ 9 -> edge ... OK > > Ok. > > The thing was marked as edge-triggered, which is basically always wrong > for a PCI interrupt. The above printout just means that it now noticed > that it was edge, and fixed it up in the ELCR. FWIW Via's PCI to ISA bridge has a PIRQ edge/level register. Vendor=1106h, Device=686h, PCI config offset 54h, RW Bits 7-4 reserved, zero. Bit 3: PIRQA# edge (clear bit for level) Bit 2: PIRQB# edge (clear bit for level) Bit 1: PIRQC# edge (clear bit for level) Bit 0: PIRQD# edge (clear bit for level) The bits are all supposed to default to zero (level). > > > - add the line "eisa_set_level_irq(irq);" to pirq_via_set() just before > > >the "return 1;" > > > > You certainly know your kernel very well... :-) > > That's why they pay me the big bucks. Good. > > I'll make it do the eisa_set_level_irq() in the generic code: it should > always be right (we don't do it now in the PIIX4 case, for example, but > the PIIX documentation actually says that we _should_), and there is no > need to do it separately for each interrupt router. So calling eisa_set_level_irq() means nothing will scream if we do not update [for example] the above register? Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: PROBLEM: kernel 2.4.0-test11-ac1 hang with usb-uhciand emu10k1
On Thu, 23 Nov 2000, Jeff Garzik wrote: > > > > It hangs in start_uhci(): > > > > /* disable legacy emulation */ > > pci_write_config_word (dev, USBLEGSUP, USBLEGSUP_DEFAULT); Try changing the thing around a bit: make the above place say /* disable legacy emulation */ pci_write_config_word (dev, USBLEGSUP, 0); and then AFTER we have successfully done a request_irq() call, we can enable PCI interrupts with /* Enable PIRQ */ pci_write_config_word (dev, USBLEGSUP, USBLEGSUP_DEFAULT); Does that make it happier? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [NEW DRIVER] firestream
Bartlomiej Zolnierkiewicz wrote: > You may also consider processing firestream.[ch] through indent because > spacing is inconsistent - sometimes tabs, sometimes 8*space (it would > be nice too have tabs everywhere). As far as I know the tabs/spaces are exactly the way I want them. There are tabs for the number of indentation levels. From then on there are only spaces. Although the "kernel-rules" say that tabs are 8 spaces, if you set your tabsize to 4, my sources should still be nicely formatted. If I'd perform your substitute it wouldn't. Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: beware of dead string constants
Bernd Eckenfels wrote: > > In article <[EMAIL PROTECTED]> you wrote: > > This is mostly a heads-up to say that in this regard gcc is not ready > > for prime time, so we really can't get away with using if() as an ifdef > > yet, at least not without penalty. > > Humm.. whats the Advantage of this? Advantage of what? If you mean preferring 'if ()' over 'ifdef'... Linus. :) And I agree with him: code looks -much- more clean without ifdefs. And the compiler should be smart enough to completely eliminate code inside an 'if (0)' code block. Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Cruft mounting option incorrect in ISOFS code
Ben Fennema wrote: > Rogier Wolff wrote: > > > > Alan Cox wrote: > > > > under 1 gig in size. You can exhibit the problem by mounting the dvd movie > > > > "The World is Not Enough" as it contains a video_ts.vob which is larger than > > > > 1 gigabyte. You will see that most of the file lengths are incorrect due to > > > > the "cruft mounting option" hacking off the high order byte. There are > > > > certainly many more movies out there that exhibit this problem so it would > > > > be a good thing for someone to fix. > > > > > The cruft thing is correct in itself. The size being 4Gb is trivial > > > to change providing someone can provide a reference to the standards > > > that say its ok. So is the limit 4Gig, who documents it ? > > > > Page 137 of DVD Demystified by Jim Taylor says: > > > > - Individual files must be less than or equal to 1 gigabyte in length. > > The maximum size of a single UDF extent is 2^30-1 > For DVD Video, the data of each file shall be recorded in a single extent. Hmm. Then the "or equal to" part is "wrong"... Yes, My dvd demystified book also says that it needs to be one extent. Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: beware of dead string constants
In article <[EMAIL PROTECTED]> you wrote: > This is mostly a heads-up to say that in this regard gcc is not ready > for prime time, so we really can't get away with using if() as an ifdef > yet, at least not without penalty. Humm.. whats the Advantage of this? Greetings Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test11: unresolved symbols
Hello all, I played around with the 'new' masquerading/network stuff for the first time. xDSL is coming to me in some days...:-) I get the following unresolved symbols with pure 2.4.0-test11. Am I missing something? depmod: *** Unresolved symbols in /lib/modules/2.4.0-test11/kernel/net/ipv4/netfilter/ip_conntrack.o depmod: nf_unregister_hook depmod: nf_unregister_sockopt depmod: nf_register_hook depmod: nf_register_sockopt depmod: *** Unresolved symbols in /lib/modules/2.4.0-test11/kernel/net/ipv4/netfilter/ip_tables.o depmod: nf_unregister_sockopt depmod: nf_register_sockopt depmod: *** Unresolved symbols in /lib/modules/2.4.0-test11/kernel/net/ipv4/netfilter/iptable_filter.o depmod: nf_unregister_hook depmod: nf_register_hook depmod: *** Unresolved symbols in /lib/modules/2.4.0-test11/kernel/net/ipv4/netfilter/iptable_nat.o depmod: nf_unregister_hook depmod: nf_register_hook depmod: *** Unresolved symbols in /lib/modules/2.4.0-test11/kernel/net/ipv6/ipv6.o depmod: rtnetlink_links depmod: sk_run_filter depmod: nf_hooks depmod: __rta_fill depmod: netlink_set_err depmod: nf_setsockopt depmod: netlink_broadcast depmod: rtnetlink_put_metrics depmod: nf_getsockopt depmod: netlink_unicast depmod: rtnl depmod: nf_hook_slow depmod: *** Unresolved symbols in /lib/modules/2.4.0-test11/kernel/net/ipv6/netfilter/ip6_tables.o depmod: nf_unregister_sockopt depmod: nf_register_sockopt depmod: *** Unresolved symbols in /lib/modules/2.4.0-test11/kernel/net/ipv6/netfilter/ip6table_filter.o depmod: nf_unregister_hook depmod: nf_register_hook depmod: *** Unresolved symbols in /lib/modules/2.4.0-test11/kernel/net/packet/af_packet.o depmod: sk_run_filter Thanks, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Too long network device names corrupts kernel
> "Tobias" == Tobias Ringstrom <[EMAIL PROTECTED]> writes: Tobias> Btw, does anyone know of a C function that works like strncpy, but does Tobias> add a terminating null character, event if the string does not fit, ro Tobias> does one have to do str[5]=0 first, and then strncpy(str,src,4)? str[0]=0; strncat(str, src, 4); Works as you want. ] Train travel features AC outlets with no take-off restrictions|gigabit is no[ ] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[ ] [EMAIL PROTECTED] www.solidum.com the little fishy gone?|PAX.port 1100[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch: linux-2.4.0-test11/drivers/sound/maestro.c port to new PCI interface
Pavel Machek wrote: > > Hi! > > > > I also agree that the ioctl patch is kind of a bandaid over > > > the problems that you described, and, while Zach Brown can speak > > > > The biggest problem is that the current code is gross gross gross. > > I've been avoiding dealing with it too much in the hopes that moving to > > oss_audio will make things much more friendly across the board. > > What is oss_audio? A module I wrote to encapsulate all the OSS logic into a single file. There are so many sound drivers that get their ioctls wrong in certain cases, don't do mmap, etc. that I moved all the logic into one place. You can obtain include/linux/oss_audio.h and drivers/sound/oss_audio.c from gkernel CVS. Check out module 'linux_2_4', tag 'hack_2_4_0_test11'. (http://sourceforge.net/projects/gkernel/) > I thought alsa is going in in 2.5... Yep. Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: PROBLEM: kernel 2.4.0-test11-ac1 hang with usb-uhci and emu10k1
Michael Elkins wrote: > > On Thu, Nov 23, 2000 at 05:49:52PM +0100, Georg Acher wrote: > > On Thu, Nov 23, 2000 at 04:35:33PM +, Rui Sousa wrote: > > > On Thu, 23 Nov 2000, Michael Elkins wrote: > > > > > > Usb controller is sharing a interrupt with the emu10k1. > > > For what I know the emu10k1 driver doesn't have any problem > > > sharing irq's, so I would blame the usb driver... > > > > usb-uhci doesn't also have any problem with sharing irqs: > > > > > cat /proc/interrupts > > 10:5597981 XT-PIC aic7xxx, eth0, usb-uhci > > > > Hm, no one left to blame... > > I would debug it as follows: > > Place various printks in the initialization code (reset_hc(), start_hc() and > > alloc_uhci) and find out after which printk it hangs. Then it would be > > possible to investigate this further... > > It hangs in start_uhci(): > > /* disable legacy emulation */ > pci_write_config_word (dev, USBLEGSUP, USBLEGSUP_DEFAULT); > > The loop that the call is in gets iterated 5 times. For i < 4, the > if (!(dev->resource[i].flags & 1)) > is TRUE, but on i==4, it drops into the bottom of the loop to execute > check_region() and then pci_write_config_word(), where it hangs. It may not make a difference, but that check is flat out wrong. Apply this patch... (untested, you may need to include ioport.h) -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso Index: drivers/usb/usb-uhci.c === RCS file: /cvsroot/gkernel/linux_2_4/drivers/usb/usb-uhci.c,v retrieving revision 1.1.1.9 diff -u -r1.1.1.9 usb-uhci.c --- drivers/usb/usb-uhci.c 2000/10/22 23:25:12 1.1.1.9 +++ drivers/usb/usb-uhci.c 2000/11/23 23:04:37 @@ -2886,7 +2886,7 @@ unsigned int io_addr = dev->resource[i].start; unsigned int io_size = dev->resource[i].end - dev->resource[i].start + 1; - if (!(dev->resource[i].flags & 1)) + if (!(dev->resource[i].flags & IORESOURCE_IO)) continue; /* Is it already in use? */
Can't mount SCSI CDROM in 2.4.*
Since I started running the 2.4.0-test kernels a couple of months ago I'm not able to use my scsi cdrom and cdwriter. Today I installed 2.4.0-test11, still the same problem. bayes:/dev# ls -l /dev/scd0 brw-rw1 root cdrom 11, 0 Oct 21 04:53 /dev/scd0 bayes:/dev# mount -t iso9660 /dev/scd0 /cdrom mount: /dev/scd0 has wrong major or minor number bayes:/dev# mount -V mount: mount-2.10o Each time I want to access the cdrom or cdwriter I have to reboot w 2.2.17 where it works fine. I've even tried with creating a generic block device bayes:/dev# ls -l /dev/scg0 brw-r--r--1 root root 21, 0 Nov 23 23:41 /dev/scg0 byes:/dev# mount -t iso9660 /dev/scg0 /cdrom mount: /dev/scg0 has wrong major or minor number Apart from this the 2.4.0-test kernels have been running very stable for me. My systems are dual PII on ASUS PL97-DS and P2B-DS According to Documentation/devices.txt nothing has changed according major numbers for these devices from 2.2 to 2.4. I'm grateful for any hint. Best regards Roland Orre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Can't mount SCSI CDROM in 2.4.*
Since I started running the 2.4.0-test kernels a couple of months ago I'm not able to use my scsi cdrom and cdwriter. Today I installed 2.4.0-test11, still the same problem. bayes:/dev# ls -l /dev/scd0 brw-rw1 root cdrom 11, 0 Oct 21 04:53 /dev/scd0 bayes:/dev# mount -t iso9660 /dev/scd0 /cdrom mount: /dev/scd0 has wrong major or minor number bayes:/dev# mount -V mount: mount-2.10o Each time I want to access the cdrom or cdwriter I have to reboot w 2.2.17 where it works fine. I've even tried with creating a generic block device bayes:/dev# ls -l /dev/scg0 brw-r--r--1 root root 21, 0 Nov 23 23:41 /dev/scg0 byes:/dev# mount -t iso9660 /dev/scg0 /cdrom mount: /dev/scg0 has wrong major or minor number Apart from this the 2.4.0-test kernels have been running very stable for me. My systems are dual PII on ASUS PL97-DS and P2B-DS According to Documentation/devices.txt nothing has changed according major numbers for these devices from 2.2 to 2.4. I'm grateful for any hint. Best regards Roland Orre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel bits
Hi! > > Can't I run a i386 kernel on a ia64 machine? I know something like this > > from HP-UX. You can choose between a 32 and a 64 bit kernel when > > installing, so knowing that you have a 64 bit capable machine does not > > say that you have a 64 bit kernel. > > And I want to have the kernel bits, not the processor bits. > > Solaris runs 32-bit kernels on 64-bit UltraSPARCs > (up to Solaris version 2.6) > > So yes, something like that MAY be possible in case > of ia64, but somehow I doubt... It definitely will be possible to run i386 linux on x86-64. -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch: linux-2.4.0-test11/drivers/sound/maestro.c port to new PCI interface
Hi! > > I also agree that the ioctl patch is kind of a bandaid over > > the problems that you described, and, while Zach Brown can speak > > The biggest problem is that the current code is gross gross gross. > I've been avoiding dealing with it too much in the hopes that moving to > oss_audio will make things much more friendly across the board. What is oss_audio? I thought alsa is going in in 2.5... Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: *** ANNOUNCEMENT *** LVM 0.8.1 and LVM 0.9 available at www.sistina.com
Hi! Perhaps yo should consider lowering number of stars in the subject. > Linux Logical Volume Manager 0.8.1 (this is 0.8final plus patches) > and 0.9 are available for download at www.sistina.com. > Please see further information below, test it and help us > to make an even better LVM for Linux :-) Question i'd like to ask: what features are already present in 2.4.0-test11? -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Address translation
Hi! > otherwise valid) I think the access macros are unnecessary. I would be > *very* glad if someone could confirm this, or shoot me down. :) > > For instance, a kernel module I am writing allocates some memory in > the current process's address space as follows: > > down(>mmap_sem); > s->table = (void **)get_unmapped_area(0, SIZEOF_TABLE); > if ( s->table != NULL ) > do_brk((unsigned long)s->table, SIZEOF_TABLE); > up(>mmap_sem); > > Some questions: > (1) In a "top half" thread, can I now access this memory without the > access macros (since I know the address range is valid)? > (2) Can I also access this memory from an interrupt/exception > context, or must I lock it? (ie. can faults be handled from such > a context) poof! I've shooted you. You may definitely access such memory from interrupt. -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Reserved root VM + OOM killer
Hi! > HOW? > No performance loss, RAM is always fully utilized (except if no swap), Handheld machines never have any swap, and alwys have little RAM [trust me, velo1 I'm writing this on is so tuned that 100KB les and machine is useless]. Unless reservation can be turned off, it is not acceptable. Okay, it can be tuned. Ok, then. [What about making default reserved space 10% of *swap* size?] -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Do you remember that oops which printed %lx instead of values?
Hi! It happened to me today while debugging x86-64. That code probably likes to fail this way ;-). Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
kernel_thread bogosity
Hi! You see? Kernel_thread does not check is sys_clone() worked! Aha, caller is responsible for that, but init/main.c does not seem too carefull. Maybe kernel_thread should at least print a warning? Plus, can someone explain me why it does not need to setup %%ecx with either zero or address of stack? Pavel int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags) { long retval, d0; __asm__ __volatile__( "movl %%esp,%%esi\n\t" "int $0x80\n\t" /* Linux/i386 system call */ "cmpl %%esp,%%esi\n\t" /* child or parent? */ "je 1f\n\t" /* parent - jump */ /* Load the argument into eax, and push it. That way, it does * not matter whether the called function is compiled with * -mregparm or not. */ "movl %4,%%eax\n\t" "pushl %%eax\n\t" "call *%5\n\t" /* call fn */ "movl %3,%0\n\t"/* exit */ "int $0x80\n" "1:\t" :"=" (retval), "=" (d0) :"0" (__NR_clone), "i" (__NR_exit), "r" (arg), "r" (fn), "b" (flags | CLONE_VM) : "memory"); return retval; } -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: kernel 2.4.0-test11-ac1 hang with usb-uhci and emu10k1
On Thu, Nov 23, 2000 at 05:49:52PM +0100, Georg Acher wrote: > On Thu, Nov 23, 2000 at 04:35:33PM +, Rui Sousa wrote: > > On Thu, 23 Nov 2000, Michael Elkins wrote: > > > > Usb controller is sharing a interrupt with the emu10k1. > > For what I know the emu10k1 driver doesn't have any problem > > sharing irq's, so I would blame the usb driver... > > usb-uhci doesn't also have any problem with sharing irqs: > > > cat /proc/interrupts > 10:5597981 XT-PIC aic7xxx, eth0, usb-uhci > > Hm, no one left to blame... > I would debug it as follows: > Place various printks in the initialization code (reset_hc(), start_hc() and > alloc_uhci) and find out after which printk it hangs. Then it would be > possible to investigate this further... It hangs in start_uhci(): /* disable legacy emulation */ pci_write_config_word (dev, USBLEGSUP, USBLEGSUP_DEFAULT); The loop that the call is in gets iterated 5 times. For i < 4, the if (!(dev->resource[i].flags & 1)) is TRUE, but on i==4, it drops into the bottom of the loop to execute check_region() and then pci_write_config_word(), where it hangs. This only seems to be a problem for initialization. If I load the usb-uhci.o module before the emu10k1.o module, everything works perfectly (no lockups). me - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net drivers cleanup
> - static unsigned char init_ID_done = 0, version_printed = 0; > - int i, irq, irqval, retval; > + static unsigned char init_ID_done, version_printed; > + int i, irq, retval; > > This is wrong because later we depend on assumption that > these values are equal to 0 (they aren't autoinitialized to 0). static starts at zero - its defined - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Address translation
On Thu, 23 Nov 2000, Andreas Bombe wrote: > > I may be wrong on this, but I thought that copy_{to,from}_user are > > only necessary if the address range you are accessing might cause a > > fault which Linux cannot handle (ie. one which would cause the > > application to segfault if it accessed that memory). If it is only a > > It is wrong. copy_*_user handle the page faults, whether they are good > faults (swapped out, copy on write) or bad faults (illegal access). > Without these macros you get the "unable to handle kernel page fault" > oops message if a fault occurs. Yes but only if it's a real fault, not if the address range actually is a valid VMA which needs paging, COW'ing or related OS ops. copy_*_user does not do the access in any different way than a "manual" access or memcpy does, it just adds a .fixup section that tells the do_page_fault handler that it should not segfault the kernel itself if the copy takes a big fault at any point, instead it should jump to the fixup which makes the copy routine return an error message. However, the fixup stuff is not in-line with the copy code so there should be absolutely no penalty using copy_*_user instead of a memcpy (provided the copy_*_user is as optimized as the memcpy code), and it's dangerous to assume anything about pages visible in user-space, they might be unmapped by another thread while you're doing that memcpy etc. > > (1) In a "top half" thread, can I now access this memory without the > > access macros (since I know the address range is valid)? > > The address is valid, the pages probably aren't. In fact, extending the > address space only creates read-only mappings to the global zeroed page > if I remember right. But it does not matter that the pages aren't there physically, any kind of access (including an access from kernel-mode) will bring about the same COW/change-on-write mechanism as copy_to_user or a user-mode access would. The problem is rather that between your do_brk and when you access the pages, a thread in the process might do an unmap or brk to remove the mapping, then you crash the kernel. > > (2) Can I also access this memory from an interrupt/exception > > context, or must I lock it? (ie. can faults be handled from such > > a context) > > You can't even use copy_*_user in this context (since the current user > space might be any process, even kernel threads that have no user space > at all). > > For access to user memory from interrupt context at all and to access > user memory without the uaccess macros, you have to lock them down in > memory, with map_user_kiobuf(). This is only recommended if you want > hardware to DMA to/from buffers provided by user space. Yup, if you are in the wrong context or in an interrupt context you'll die horribly if you try to access user-pages that aren't there: if (in_interrupt() || !mm) goto no_context; So you need to 1) make sure the pages are in physical memory and 2) make sure the pages won't get removed from under your feet at any time and 3) access them using their physical address > > (3) Is the above code sensible at all, or barking? It took me a while > > to figure that the above would work, and I think/hope it is the > > most elegant way to share memory between kernel and a process. > > It will fail quickly, probably taking the kernel down with it. > > The most elegant way to share memory between user and kernel is to > allocate the memory in the kernel and map it to user space (by > implementing mmap on the kernel side for the file used for > communication). Agreed, but that does not cut it for some applications. For example, let's say you want to grab 16 MB of video frames without copying them from that mmap area to your malloc'ed 16 MB (let's say your CPU takes a pretty big hit doing that extra memcpy) and you'd like to DMA directly into the user-pages. You can of course make the kernel grab 16 MB worth of pages for you and then mmap them into the process, but the kernel driver would be pretty hooked to that demanding user process then.. Actually I'm trying to figure out the best way to do a similar thing for some hardware we have - I have incoming DMA data containing JPG grabs, and I want to cache images in a user-mode daemon, which will send pictures from the cache out on TCP. The images might be generated with many different JPG settings so they need right tags in the cache etc. Before when we ran on a chip without MMU this was easy - that user-mode buffer was a contigous physical area which I could DMA directly in. But now when we're going to a CPU with MMU, it gets more complicated of course :) I have figured the options are 1) let the kernel driver have a buffer big enough for a single grab, mmap this into user-space and do the memcpy into the cache (might be fast enough, but our chip isn't super on memcpy's..) 2) let the kernel driver lock down the user-pages in an access and DMA directly
Re: [PATCH] net drivers cleanup
Hi patch-3c503: @@ -307,11 +307,12 @@ { ei_status.tx_start_page = EL2_MB1_START_PG; ei_status.rx_start_page = EL2_MB1_START_PG + TX_PAGES; - printk("\n%s: %s, %dkB RAM, using programmed I/O (REJUMPER for SHARED MEMORY).\n", - dev->name, ei_status.name, (wordlength+1)<<3); + printk( KERN_ERR "\n%s: %s, %dkB RAM, using programmed I/O (REJUMPER for +SHARED MEMORY).\n", --> ^^ superfluous + dev->name, ei_status.name, (wordlength+1)<<3); Either remove this '\n' or change to ("\n" KERN_ERR "%s...\n"). patch-3c507: @@ -323,8 +323,8 @@ static int __init el16_probe1(struct net_device *dev, int ioaddr) { - static unsigned char init_ID_done = 0, version_printed = 0; - int i, irq, irqval, retval; + static unsigned char init_ID_done, version_printed; + int i, irq, retval; This is wrong because later we depend on assumption that these values are equal to 0 (they aren't autoinitialized to 0). patch-lne390: @@ -121,14 +121,14 @@ if (!EISA_bus) { #if LNE390_DEBUG & LNE390_D_PROBE - printk("lne390-debug: Not an EISA bus. Not probing high ports.\n"); + printk(kern_debug "lne390-debug: Not an EISA bus. Not probing high +ports.\n"); ^^ should be KERN_DEBUG of course ;) patch-wd: @@ -124,7 +124,7 @@ int ancient = 0;/* An old card without config registers. */ int word16 = 0; /* 0 = 8 bit, 1 = 16 bit */ const char *model_name; - static unsigned version_printed = 0; + static unsigned version_printed; This is wrong because later we depend on assumption that version_printed is equal to 0 (it isn't autoinitialized to 0). Regards -- Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [NEW DRIVER] firestream
Hi! Just a few hints on __init/__exit stuff... On Wed, 22 Nov 2000, Patrick van de Lageweg wrote: > +struct reginit_item PHY_NTC_INIT[] = { Can be marked __initdata > +void undocumented_pci_fix (struct pci_dev *pdev) Can be marked __init > +void write_phy (struct fs_dev *dev, int regnum, int val) Can be marked __init > +int init_phy (struct fs_dev *dev, struct reginit_item *reginit) Can be marked __init > +void *aligned_kmalloc (int size, int flags, int alignment) Can be marked __init > +int init_q (struct fs_dev *dev, > + struct queue *txq, int queue, int nentries, int is_rq) Can be marked __init > +int init_fp (struct fs_dev *dev, > + struct freepool *fp, int queue, int bufsize, int nr_buffers) Can be marked __init > +void free_queue (struct fs_dev *dev, struct queue *txq) Can be marked __exit > +void free_freepool (struct fs_dev *dev, struct freepool *fp) Can be marked __exit You may also consider processing firestream.[ch] through indent because spacing is inconsistent - sometimes tabs, sometimes 8*space (it would be nice too have tabs everywhere). Regards -- Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.18pre, usb mouse messages
Hi, I use an USB mouse, it works perfectly both with 'gpm' and with X-window but time to time, I've this kind of message stream : [root@debian-f5ibh] ~ # usb-uhci.c: interrupt, status 3, frame# 20 usb-uhci.c: interrupt, status 3, frame# 44 usb-uhci.c: interrupt, status 3, frame# 68 usb-uhci.c: interrupt, status 3, frame# 92 usb-uhci.c: interrupt, status 3, frame# 116 usb-uhci.c: interrupt, status 3, frame# 140 usb-uhci.c: interrupt, status 3, frame# 164 usb-uhci.c: interrupt, status 3, frame# 188 usb-uhci.c: interrupt, status 3, frame# 212 hub.c: already running port 2 disabled by hub (EMI?), re-enabling... This message appears with most (all ?) of the 2.2.18pre releases, the actual one is 2.2.18pre23. Computer is pentium 200MMX, 64Mb SDRAM. Relevant CONFIG bits : -- # USB support # CONFIG_USB=m # CONFIG_USB_DEBUG is not set # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y CONFIG_HOTPLUG=y # CONFIG_USB_BANDWIDTH is not set # # USB Controllers # CONFIG_USB_UHCI=m # CONFIG_USB_UHCI_ALT is not set # CONFIG_USB_OHCI is not set # # USB Devices # # CONFIG_USB_PRINTER is not set # CONFIG_USB_SCANNER is not set # CONFIG_USB_AUDIO is not set # CONFIG_USB_ACM is not set # CONFIG_USB_SERIAL is not set # CONFIG_USB_IBMCAM is not set # CONFIG_USB_OV511 is not set # CONFIG_USB_DC2XX is not set # CONFIG_USB_MDC800 is not set # CONFIG_USB_STORAGE is not set # CONFIG_USB_DABUSB is not set # CONFIG_USB_PLUSB is not set # CONFIG_USB_PEGASUS is not set # # USB HID # CONFIG_USB_HID=m # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_WMFORCE is not set # CONFIG_INPUT_KEYBDEV is not set CONFIG_INPUT_MOUSEDEV=m CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_EVDEV is not set boot messages : --- usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb.c: registered new driver hid usb-uhci.c: $Revision: 1.237 $ time 23:53:07 Nov 23 2000 usb-uhci.c: High bandwidth mode enabled usb-uhci.c: USB UHCI at I/O 0x6100, IRQ 11 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 1 usb.c: USB new device connect, assigned device number 1 hub.c: USB hub found hub.c: 2 ports detected mice: PS/2 mouse device common for all mice usb.c: USB new device connect, assigned device number 2 mouse0: PS/2 mouse device for input0 input0: USB HID v1.00 Mouse [Cypress Sem. Cypress USB Mouse] on usb1:2.0 hub.c: already running port 2 disabled by hub (EMI?), re-enabling... usb.c: USB disconnect on device 2 usb.c: USB new device connect, assigned device number 2 mouse0: PS/2 mouse device for input0 input0: USB HID v1.00 Mouse [Cypress Sem. Cypress USB Mouse] on usb1:2.0 Regards Jean-Luc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: {PATCH} isofs stuff
On Thu, 23 Nov 2000, Matti Aarnio wrote: > On Thu, Nov 23, 2000 at 12:38:55PM -0800, Linus Torvalds wrote: > ... > > In fact, almost all filesystems do this at some point. ext2 does it for > > directories too, for some very similar reasons that isofs does. See > > fs/ext2/dir.c: > > > > blk = (filp->f_pos) >> EXT2_BLOCK_SIZE_BITS(sb); > > > > (and don't ask me about the extraneous parenthesis. I bet some LISP > > programmer felt alone and decided to make it a bit more homey). > > > > Linus > >Propably some programmer has been bitten once too many times with >C's operator precedence rules, which only affect more complicated >expressions -- and thus are used rarely, and not remembered well. Come again? Precedence or not, how in hell could anything be stronger than -> or . on the _right_ side? Field names are atoms, you can't have an expression there... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Recent ide patches and DMA
With recent ide patches, the ide driver seems to try to use DMA mode even for a drive which dosen't support it. CONFIG_IDEDMA_PCI_AUTO is enabled but even so with the stock kernel this dosen't happen. older patches didn't have this behavior either. Is this change intentional ? hdc: 333630 sectors (171 MB) w/32KiB Cache, CHS=1011/15/22, DMA Partition check: hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 > hdc:hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdc: dma_intr: error=0x04 { DriveStatusError } hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdc: dma_intr: error=0x04 { DriveStatusError } hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdc: dma_intr: error=0x04 { DriveStatusError } hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdc: dma_intr: error=0x04 { DriveStatusError } hdc: DMA disabled ide1: reset: success hdc1 ~ $ hdparm -i /dev/hdc /dev/hdc: Model=QUANTUM ELS170A, FwRev=4.20, SerialNo=166304085456 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>5Mbs RotSpdTol>.5% } RawCHS=1011/15/22, TrkSize=11264, SectSize=512, ECCbytes=4 BuffType=3(DualPortCache), BuffSize=32kB, MaxMultSect=8, MultSect=off DblWordIO=no, OldPIO=2, DMA=no CurCHS=1011/15/22, CurSects=333629, LBA=no This may not be a major problem, as nobody probably uses such an obsolete drive nowadays. The following patches have been tried: ide.2.2.18-22.all.20001120 ide.2.4.0-t11.1120.patch Free Web space and web based email @EASYNEWS.COM - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ext2 filesystem corruptions back from dead? 2.4.0-test11
I'm still trying to reproduce the darn thing w/o the patch. No luck so far. Maybe I'll put some mission critical stuff on my machine. Then it'll pop up like clock works. Thats the way everythign is supposed to work right? =) Tigran Aivazian wrote: > However, I can't say that _without_ your patch the above did _not_ > survive. The corruptions usually come from real useful work and not from > articfical tests (unfortunately) -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Raising MAX_UNITS in net drivers oopses kernel reproducibly
Hello all, Using RHL 2.2.16-3 kernel on i686. Raising MAX_UNITS define from 8 to 16 or 32 in net drivers (tested tulip.c) causes reproducible oops. The latest Don Becker driver also does this. Using DFE-570TX quad ethernet cards. So, why change MAX_UNITS? Interfaces 9-> can't be passed options=, full_duplex= or similar parameters otherwise. The actual interfaces should work in autonegotiation though. I've gotten this crash every time. It can be done as follows: 1) recompile a new tulip module with changed MAX_UNITS. 2) insmod the module 3) take one interface up, with e.g. ifup eth0. [note: traffic doesn't go anywhere] 4) try to take the interface down, with e.g. ifconfig eth0 5) watch oops in your syslog. Previous message on syslog was 'Trying to free free IRQ9'. See below: - Unable to handle kernel paging request at virtual address 109f current->tss.cr3 = 01d69000, %%cr3 = 01d69000 *pde = Oops: CPU:0 EIP:0010:[de4x5:de4x5_probe+24259/37172] EFLAGS: 00010282 eax: c4056f00 ebx: 1043 ecx: 0246 edx: esi: 1043 edi: c38cc5a0 ebp: c103deb4 esp: c103deac ds: 0018 es: 0018 ss: 0018 Process ifconfig (pid: 1924, process nr: 7, stackpage=c103d000) Stack: c38cc480 1042 c014fe92 c38cc5a0 1043 c38cc5a0 c0150980 c38cc5a0 c29c6300 1042 c29c6324 c103df40 c0170f9c c38cc5a0 1042 8914 8914 b9f4 c2671740 8913 c103df40 c0150ee9 Call Trace: [dev_close+78/156] [dev_change_flags+80/268] [devinet_ioctl+620/1404] [dev_ioctl+337/792] [inet_ioctl+294/412] [free_pages+36/40] [sock_ioctl+29/36] [sys_ioctl+421/448] [system_call+52/56] Code: 8b 56 5c 31 c0 0f ab 46 24 19 c0 85 c0 74 29 a1 80 47 21 c0 - Note! EIP shows de4x5 for some reason. Please note that de4x5 driver also "works" with this card. The driver is _really_ buggy with it though. With Don Becker drivers the output is about the same; EIP is __insmod_tulip_S and Call Trace: begins with dev_deactivate. Any ideas? _Should_ raising MAX_UNITS work as I described or are there any known problems with it? Please Cc:. -- Pekka Savola "Tell me of difficulties surmounted, [EMAIL PROTECTED] not those you stumble over and fall" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
mm->rss modified without the page_table_lock (revisited)
Hi. Some time ago there was a thread about subject and a patch was posted (by davej?). It was rejected because of the vmlist_modify_{un}lock mess (AFAIR) and nothing has been done since. The first patch below moves mm->rss inside the page_table_lock in mm/. I noticed that mm->rss is also modified in fs/{exec.c,binfmt_aout.c, binfmt_elf.c} without the lock being held. Am I missing something or are these buggy too? I have no idea of what assumptions can be made in these code paths so I have not tried to produce patches for them. Patch against 240-test11. Please comment. diff -uar linux-240-t11/mm/memory.c linux/mm/memory.c --- linux-240-t11/mm/memory.c Wed Nov 22 22:41:45 2000 +++ linux/mm/memory.c Thu Nov 23 21:45:58 2000 @@ -369,7 +369,6 @@ address = (address + PGDIR_SIZE) & PGDIR_MASK; dir++; } while (address && (address < end)); - spin_unlock(>page_table_lock); /* * Update rss for the mm_struct (not necessarily current->mm) * Notice that rss is an unsigned long. @@ -378,6 +377,7 @@ mm->rss -= freed; else mm->rss = 0; + spin_unlock(>page_table_lock); } @@ -1074,7 +1074,9 @@ flush_icache_page(vma, page); } + spin_lock(>page_table_lock); mm->rss++; + spin_unlock(>page_table_lock); pte = mk_pte(page, vma->vm_page_prot); @@ -1113,7 +1115,9 @@ return -1; clear_user_highpage(page, addr); entry = pte_mkwrite(pte_mkdirty(mk_pte(page, vma->vm_page_prot))); + spin_lock(>page_table_lock); mm->rss++; + spin_unlock(>page_table_lock); flush_page_to_ram(page); } set_pte(page_table, entry); @@ -1152,7 +1156,9 @@ return 0; if (new_page == NOPAGE_OOM) return -1; + spin_lock(>page_table_lock); ++mm->rss; + spin_unlock(>page_table_lock); /* * This silly early PAGE_DIRTY setting removes a race * due to the bad i386 page protection. But it's valid diff -uar linux-240-t11/mm/mmap.c linux/mm/mmap.c --- linux-240-t11/mm/mmap.c Wed Nov 22 22:41:45 2000 +++ linux/mm/mmap.c Thu Nov 23 21:45:58 2000 @@ -889,8 +889,8 @@ spin_lock(>page_table_lock); mpnt = mm->mmap; mm->mmap = mm->mmap_avl = mm->mmap_cache = NULL; - spin_unlock(>page_table_lock); mm->rss = 0; + spin_unlock(>page_table_lock); mm->total_vm = 0; mm->locked_vm = 0; while (mpnt) { diff -uar linux-240-t11/mm/swapfile.c linux/mm/swapfile.c --- linux-240-t11/mm/swapfile.c Sat Nov 4 23:27:17 2000 +++ linux/mm/swapfile.c Thu Nov 23 21:45:58 2000 @@ -231,7 +231,9 @@ set_pte(dir, pte_mkdirty(mk_pte(page, vma->vm_page_prot))); swap_free(entry); get_page(page); + spin_lock(>vm_mm->page_table_lock); ++vma->vm_mm->rss; + spin_unlock(>vm_mm->page_table_lock); } static inline void unuse_pmd(struct vm_area_struct * vma, pmd_t *dir, diff -uar linux-240-t11/mm/vmscan.c linux/mm/vmscan.c --- linux-240-t11/mm/vmscan.c Wed Nov 22 22:41:45 2000 +++ linux/mm/vmscan.c Thu Nov 23 21:45:58 2000 @@ -95,7 +95,9 @@ set_pte(page_table, swp_entry_to_pte(entry)); drop_pte: UnlockPage(page); + spin_lock(>page_table_lock); mm->rss--; + spin_unlock(>page_table_lock); flush_tlb_page(vma, address); deactivate_page(page); page_cache_release(page); -- Regards, Rasmus([EMAIL PROTECTED]) Gates' Law: Every 18 months, the speed of software halves -- Anonymous - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ext2 filesystem corruptions back from dead? 2.4.0-test11
Hi Alexander, I am "hammering" an ext2 filesystem with all sorts (bonnies, make -j8 bzImage, cp -a dir1 dir2 + all these over localhost NFSv3) for a while and so far it survives. The system is 2way SMP with 1G RAM. However, I can't say that _without_ your patch the above did _not_ survive. The corruptions usually come from real useful work and not from articfical tests (unfortunately) Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Address translation
On Wed, Nov 22, 2000 at 09:39:51PM +, Keir Fraser wrote: > > The reason that everyone else uses copy_{to,from}_user is that there > > is no way to guarantee that the userspace pointer is valid. That > > memory may have been swapped out. The copy macros are prepared to > > fault the memory in. The rest of the kernel is not. > > > > Jeff > > I may be wrong on this, but I thought that copy_{to,from}_user are > only necessary if the address range you are accessing might cause a > fault which Linux cannot handle (ie. one which would cause the > application to segfault if it accessed that memory). If it is only a > matter of paging the memory in (and you are _sure_ the address range is > otherwise valid) I think the access macros are unnecessary. I would be > *very* glad if someone could confirm this, or shoot me down. :) It is wrong. copy_*_user handle the page faults, whether they are good faults (swapped out, copy on write) or bad faults (illegal access). Without these macros you get the "unable to handle kernel page fault" oops message if a fault occurs. > For instance, a kernel module I am writing allocates some memory in > the current process's address space as follows: > > down(>mmap_sem); > s->table = (void **)get_unmapped_area(0, SIZEOF_TABLE); > if ( s->table != NULL ) > do_brk((unsigned long)s->table, SIZEOF_TABLE); > up(>mmap_sem); > > Some questions: > (1) In a "top half" thread, can I now access this memory without the > access macros (since I know the address range is valid)? The address is valid, the pages probably aren't. In fact, extending the address space only creates read-only mappings to the global zeroed page if I remember right. > (2) Can I also access this memory from an interrupt/exception > context, or must I lock it? (ie. can faults be handled from such > a context) You can't even use copy_*_user in this context (since the current user space might be any process, even kernel threads that have no user space at all). For access to user memory from interrupt context at all and to access user memory without the uaccess macros, you have to lock them down in memory, with map_user_kiobuf(). This is only recommended if you want hardware to DMA to/from buffers provided by user space. > (3) Is the above code sensible at all, or barking? It took me a while > to figure that the above would work, and I think/hope it is the > most elegant way to share memory between kernel and a process. It will fail quickly, probably taking the kernel down with it. The most elegant way to share memory between user and kernel is to allocate the memory in the kernel and map it to user space (by implementing mmap on the kernel side for the file used for communication). -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: {PATCH} isofs stuff
On Thu, Nov 23, 2000 at 12:38:55PM -0800, Linus Torvalds wrote: ... > In fact, almost all filesystems do this at some point. ext2 does it for > directories too, for some very similar reasons that isofs does. See > fs/ext2/dir.c: > > blk = (filp->f_pos) >> EXT2_BLOCK_SIZE_BITS(sb); > > (and don't ask me about the extraneous parenthesis. I bet some LISP > programmer felt alone and decided to make it a bit more homey). > > Linus Propably some programmer has been bitten once too many times with C's operator precedence rules, which only affect more complicated expressions -- and thus are used rarely, and not remembered well. (Or perhaps rememberance is felt to be weak, and parenthesis solve it.) /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: {PATCH} isofs stuff
On Thu, 23 Nov 2000, Andi Kleen wrote: > > I am actually not sure if the normal kernel contains even a variable > width long long shift. Sure it does. The isofs code contains exctly that: block = filp->f_pos >> bufbits; In fact, almost all filesystems do this at some point. ext2 does it for directories too, for some very similar reasons that isofs does. See fs/ext2/dir.c: blk = (filp->f_pos) >> EXT2_BLOCK_SIZE_BITS(sb); (and don't ask me about the extraneous parenthesis. I bet some LISP programmer felt alone and decided to make it a bit more homey). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentacion proc.txt update (2.4.x)
On Tue, 21 Nov 2000, Jorge Nerin wrote: >> How about a working URL? >> >> traceroute to skaro.nightcrawler.com (216.186.140.118), 30 hops max, 38 byte packets >> [...] >> 11 pos3-0-0-155M.sjc-bb3.cerf.net (134.24.29.26) 66.400 ms 74.860 ms 68.486 ms >> 12 dslnetworks1.dslnetworks.com (206.19.42.193) 105.303 ms 86.436 ms 68.749 ms >> 13 206.16.72.114 (206.16.72.114) 79.867 ms 63.365 ms 59.919 ms >> 14 * * * >> 15 * * * >> >> -Dan > >Well, the URL came with the text, it was there before me ;-) I didn't >work for me either, but I left it because I don't have a URL with the >updated version online, even I don't have an updated version, I had to >do it myself. > >I have left it because I don't have replies from the author nor from the >website. No information is always better than misinformation. -- Mike A. Harris - Linux advocate - Open source advocate This message is copyright 2000, all rights reserved. Views expressed are my own, not necessarily shared by my employer. -- And 1.1.81 is officially BugFree(tm), so if you receive any bug-reports on it, you know they are just evil lies. -- Linus Torvalds - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: silly [< >] and other excess
Albert D. Cahalan writes: > Also, cross-arch debugging is done by people who don't need tools > like ksymoops anyway. Most likely they have half the opcodes > memorized already, and they have the CPU manual open on their desk. I certainly don't have each of the 4 billion opcode combinations on the ARM memorised, and I've been hacking ARM code for over 12 years now. > I threw together a semi-working prototype in a few hours. > It is the worst code I ever wrote in my life, not even > excluding stuff I wrote in Atari BASIC. It slurps down log > files pretty well though, and proves "[<>]" is unneeded. Oh, how have you proven it? Have you proven it with that ARM oops that appeared on this list? How do you know that it has produced the right output for the developers? _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VMWare will not run on kernel 2.4.0-test11
> vmware-2.0.3-786 refused to run. Running vmware-config.pl resulted in a > the following message: Run 2.4.0-test11-ac3 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VMWare will not run on kernel 2.4.0-test11
On Thu, Nov 23, 2000 at 12:07:01PM -0800, Phil Stracchino wrote: > I just compiled and installed kernel 2.4.0-test11. Upon rebooting, > vmware-2.0.3-786 refused to run. Running vmware-config.pl resulted in a > the following message: > > "Your processor does not have a Time Stamp Counter. VMware will >not run on this system." > > Since (1) my hardware has not changed, (2) this VMware release ran > perfectly on 2.4.0-test10, and (3) I changed nothing but the kernel in > between 2.4.0-test10 and 2.4.0-test11, I feel quite confident in believing > that I do indeed possess a Time Stamp Counter (whatever such a fabulous > beast may be), but for some reason VMware is unable to detect its presence > when running on kernel 2.4.0-test11. Evidently there has been some change > in the kernel which renders VMware unable to detect this mysterious - but > apparently crucial - feature. > > > I would appreciate any insights from either kernel folks or VMware folks > as to where this problem may lie, with an eventual aim of patching either > VMware or the kernel to allow VMware to run on this kernel. > It's probably due to /proc/cpuinfo change - 'flags' has changed to 'features'. Jan Dvorak <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: silly [< >] and other excess
On Thu, 23 Nov 2000, Charles Cazabon wrote: > [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Thats because too many things get put on a line then. > > > And because we do [] [] not [][] ? > > > > In the good old times we had foo bar for a total of 8*(8+1) = 72 > > positions. Now we have [] [] which takes 8*(8+1+4) = 104 > > positions. If you turned this into 6 items per line instead of 8, > > it would certainly improve matters a bit. > > The original poster complained the output lines were too wide for the screen > on his PC. Perhaps he should change his console mode to 132 characters wide > (via SVGATextMode or such) -- voila, no more problem, no broken kernel patches. Well that 72 characters is also known as the "safe" email line length... ... and besides some people still use the old VT330s and alike ;) But in practice even those 79 chars would be better than 104. -- No .sig here... especially no 128x48 .sig here - nor 132xYuch... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VMWare will not run on kernel 2.4.0-test11
Tiny patch for vmware-config.pl Phil Stracchino wrote: > > I just compiled and installed kernel 2.4.0-test11. Upon rebooting, > vmware-2.0.3-786 refused to run. Running vmware-config.pl resulted in a > the following message: > > "Your processor does not have a Time Stamp Counter. VMware will > not run on this system." > -- = 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] = --- vmware-config.pl.oldThu Nov 23 15:12:32 2000 +++ vmware-config.plThu Nov 23 15:12:55 2000 @@ -1113,7 +1113,7 @@ if (direct_command(shell_string($gHelper{'grep'}) . ' ' . shell_string('^cpuid') . ' /proc/cpuinfo') eq '') { error('Your ' . (($gSystem{'smp'} eq 'yes') ? 'processors do' : 'processor does') . ' not support the cpuid instruction. VMware will not run on this system.' . "\n\n"); } - if (direct_command(shell_string($gHelper{'grep'}) . ' ' . shell_string('^flags.* tsc') . ' /proc/cpuinfo') eq '') { + if (direct_command(shell_string($gHelper{'grep'}) . ' ' . shell_string('^features.* +tsc') . ' /proc/cpuinfo') eq '') { error('Your ' . (($gSystem{'smp'} eq 'yes') ? 'processors do' : 'processor does') . ' not have a Time Stamp Counter. VMware will not run on this system.' . "\n\n"); } }
Re: alloc_tty_struct() question.
On Thu, Nov 23, 2000 at 06:54:48PM +, Tigran Aivazian wrote: > Hi, > > The sizeof(struct tty_struct) = 3084. Why don't we have a private slab > cache for it instead of getting a page and wasting some precious bytes at > the end? Potentially, we can have thousands of tty_struct allocated > (assuming we have thousands of concurrent users)... A slab cache could only save significant memory if it allocated in order 2 slabs (order 1 would waste exactly the same memory because you only had a ~2K gap) Order 2 is nasty and unreliable. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: {PATCH} isofs stuff
On Thu, Nov 23, 2000 at 08:59:46AM -0800, Linus Torvalds wrote: > [ Btw, I noticed that one of my machines _does_ have gcc-2.95.2, so I can > look at the isofs code generation myself. I don't see anything obvious, > and the code is hairy. The differences between 2.91.66 and 2.95.2 are > big enough that a plain "diff" doesn't show anything clear. Andi, what > does your test-case look like? ] Just a variable width shift of long long with both arguments fetched from deep indirection via pointers, and that all in a function with register pressure (extracted from the XFS source, which does all kinds of nasty things with long long) I am actually not sure if the normal kernel contains even a variable width long long shift. -Andi (who also sees some strange hangs in 2.4.0test11-pre, but more suspects his own hacks. no fs corruption, but I do not run dbench normally) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: Modularize /proc/partitons (was Re: /proc/partitions for LVM)
"Heinz J. Mauelshagen" wrote: > > On Wed, Nov 22, 2000 at 04:27:51PM -0500, Brian Kress wrote: > > "Heinz J. Mauelshagen" wrote: > > > > > > On Wed, Nov 22, 2000 at 04:05:39PM -0500, Brian Kress wrote: > > > > Question about /proc/partitions and LVM. LVM devices in > > > > /proc/partitions currently show up as lvma, lvmb, etc, depending on > > > > their device number. This breaks things like mount by filesystem > > > > name. Back when LVM existed as a patch, I believe there was some > > > > support in fs/partitions/check.c for showing the proper name for > > > > the device (something like /). > > > > > > Yes. > > > It actually was /. > > > > > > Linus didn't accept it though. > > > > > > The code is still available in case he changes his mind. > > > > Yes, I can see that now looking through lvm.c. (LVM_HD_NAME) > > I'm guessing why he didn't take it is the minor hack of adding a > > function pointer to genhd.c as a special case just for LVM. > > A general solution to this problem would be nice. The > > big switch statement in disk_name in fs/paritions/check.c is kind > > of ugly as it has generic code have to know things about specific > > drivers. > > Yep. > > > How's this for an idea to generalize this. Put a function > > pointer in the gendisk structure for a specific function to call > > for disk_name for disks for that gendisk. > > Sounds resonable to me. > > > That way, LVM gets its > > /, IDE gets its two disks per major (special cased > > right now), all the other special cases get what they need and future > > drivers can call their devices whatever they like without touching > > this file. Makes the whole thing more modular. Make a NULL for > > this function default to the old a, b, etc. > > What to people think about this? If this sounds reasonable > > I can come up with a patch. > > Very good. I'ld appreciate it. > OK, here's the patch. It has three sets of changes: 1) Add a function pointer to struct gendisk called hd_name. 2) Make disk_name in fs/partitions/check.c use that function pointer if its non-null. 3) Change the following drivers to use this method. (adding the driver specific method and removing the old code in check.c) drivers/md/lvm.c drivers/md/md.c drivers/ide/ide-probe.c drivers/scsi/sd.c drivers/block/cpqarray.c drivers/block/cciss.c drivers/block/DAC960.c Let me know what you think. Think there's any chance we can get this in the main kernel tree? Brian Kress [EMAIL PROTECTED] diff -u --recursive linux-2.4.0-test11/drivers/block/DAC960.c linux-2.4.0-test11-ppfix/drivers/block/DAC960.c --- linux-2.4.0-test11/drivers/block/DAC960.c Mon Nov 20 15:17:25 2000 +++ linux-2.4.0-test11-ppfix/drivers/block/DAC960.c Thu Nov 23 14:29:37 2000 @@ -1885,6 +1885,21 @@ } +char *DAC960_disk_name(struct gendisk *hd, int minor, char *buf) + +{ + int ctlr = hd->major - DAC960_MAJOR; + int disk = minor >> hd->minor_shift; + int part = minor & ((1 << hd->minor_shift) - 1); + + if (part) + sprintf(buf, "%s/c%dd%dp%d", hd->major_name, ctlr, disk, part); + else + sprintf(buf, "%s/c%dd%d", hd->major_name, ctlr, disk); + return buf; +} + + /* DAC960_RegisterBlockDevice registers the Block Device structures associated with Controller. @@ -1945,6 +1960,7 @@ Controller->GenericDiskInfo.nr_real = Controller->LogicalDriveCount; Controller->GenericDiskInfo.next = NULL; Controller->GenericDiskInfo.fops = _BlockDeviceOperations; + Controller->GenericDiskInfo.hd_name = DAC960_disk_name; /* Install the Generic Disk Information structure at the end of the list. */ diff -u --recursive linux-2.4.0-test11/drivers/block/cciss.c linux-2.4.0-test11-ppfix/drivers/block/cciss.c --- linux-2.4.0-test11/drivers/block/cciss.cMon Nov 20 15:17:25 2000 +++ linux-2.4.0-test11-ppfix/drivers/block/cciss.c Thu Nov 23 14:22:55 2000 @@ -1749,6 +1749,20 @@ kfree(size_buff); } +char *cciss_disk_name(struct gendisk *hd, int minor, char *buf) + +{ + int ctlr = hd->major - COMPAQ_CISS_MAJOR; + int disk = minor >> hd->minor_shift; + int part = minor & ((1 << hd->minor_shift) - 1); + + if (part) + sprintf(buf, "%s/c%dd%dp%d", hd->major_name, ctlr, disk, part); + else + sprintf(buf, "%s/c%dd%d", hd->major_name, ctlr, disk); + return buf; +} + /* * This is it. Find all the controllers and register them. I really hate * stealing all these major device numbers. @@ -1851,6 +1865,7 @@ hba[i]->gendisk.part = hba[i]->hd; hba[i]->gendisk.sizes = hba[i]->sizes; hba[i]->gendisk.nr_real = hba[i]->num_luns; + hba[i]->gendisk.hd_name = cciss_disk_name; /* Get on the disk list */ hba[i]->gendisk.next = gendisk_head; diff -u --recursive linux-2.4.0-test11/drivers/block/cpqarray.c
Re: Strange lockup of the timer with 2.4.0-test10 SMP (and older)
Dans son message du Thu 23 November, Maciej W. Rozycki ecrit : > Hmm, your BIOS reports the timer IRQ is directly connected... > > Int: type 0, pol 3, trig 3, bus 2, IRQ 09, APIC ID 2, APIC INT 09 > This is weird for an ISA IRQ. Remember that I have TWO PCI buses and one ISA Bus. > > > ENABLING IO-APIC IRQs > > ...changing IO-APIC physical APIC ID to 2 ... ok. > > BIOS bug, IO-APIC#1 ID 3 is already used!... > > ... fixing up to 1. (tell your hw vendor) > > ...changing IO-APIC physical APIC ID to 1 ... ok. > This is annoying but Linux recovers from it... Yes. I had to patch 2.4.0pre2 to be able to boot, but now it boots unpatched. Why do you mean by "annoying" ? I thought this was just an initialization problem. By the way, my BIOS has an option to choose between MP 1.4 or older specifications. Changing it has not changed anything to the problem. > > ..TIMER: vector=49 pin1=2 pin2=0 > > ..MP-BIOS bug: 8254 timer not connected to IO-APIC > > ...trying to set up timer (IRQ0) through the 8259A ... > > . (found pin 0) ...works. > > At the moment I can't see any reason of this failure apart from pin1 > being unconnected. But why would it be? I'll prepare a debugging patch > which might help finding the real cause and I'll send it to you soon. Okay. Thank you very much. > BTW, have you checked if there is a BIOS update for your system? I will check that with Asus. At this time I have BIOS 1002. -- | Benjamin Monate | mailto:[EMAIL PROTECTED] | | LRI - Bât. 490 | Université de Paris-Sud | F-91405 ORSAY Cedex - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Power-off doesn't work in 2.4.0test11
Hi, Since I use kernel 2.4.0(test11) the power-off on halt doesn't work anymore (I have the same problem with previous 2.4.0 releases). I use apm to power-off the system (my system doesn't support acpi) and with kernel 2.2.17 everything works great. But since I've compiled 2.4.0test11 with exactly the same configuration, my system doesn't power-off anymore. I use a celeron 266@400MHz with a BX-pro mainboard with an ALi chipset. Does anyone know how I get my system to power-off again? Thanx, Jeroen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] O_SYNC patch 3/3, add inode dirty buffer list support to ext2
On Thu, Nov 23, 2000 at 12:01:35PM +, Stephen C. Tweedie wrote: > Hi, > > On Wed, Nov 22, 2000 at 11:54:24AM -0700, Jeff V. Merkey wrote: > > > > I have not implemented O_SYNC in NWFS, but it looks like I need to add it > > before posting the final patches. This patch appears to force write-through > > of only dirty inodes, and allow reads to continue from cache. Is this > > assumption correct > > Yes: O_SYNC is not required to force reads to be made from disk. > SingleUnix has an "O_RSYNC" option which does that, but O_SYNC and > O_DSYNC don't imply that. Cool. ORACLE is going to **SMOKE** on EXT2 with this change. Jeff > > Cheers, > Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: alloc_tty_struct() question.
On Thu, Nov 23, 2000 at 06:54:48PM +, Tigran Aivazian wrote: > Hi, > > The sizeof(struct tty_struct) = 3084. Why don't we have a private slab > cache for it instead of getting a page and wasting some precious bytes at > the end? Potentially, we can have thousands of tty_struct allocated > (assuming we have thousands of concurrent users)... Potentially thousands, in practice some 10-30. Wastage will be worse with 8k pages, of course. > regards, > Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
alloc_tty_struct() question.
Hi, The sizeof(struct tty_struct) = 3084. Why don't we have a private slab cache for it instead of getting a page and wasting some precious bytes at the end? Potentially, we can have thousands of tty_struct allocated (assuming we have thousands of concurrent users)... regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
oddity introduced between 2.4.0-test10 & -test11
hot-pluggable devices are turned off in the config (see below). -test9 had some problems with depmod arguments, make completed if i used '-' in the Makefile to ignore the status and went back to run depmod by hand. make[1]: Leaving directory `/usr/src/linux-2.4.0-test11/arch/i386/lib' cd /lib/modules/2.4.0-test11; \ mkdir -p pcmcia; \ find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{} pcmcia if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.4.0-test11; fi depmod: depmod.c:482: addksyms: Assertion `n_syms < 1' failed. make: *** [_modinst_post] Error 134 enjoi, sl # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set CONFIG_M686FXSR=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_FXSR=y CONFIG_X86_XMM=y # CONFIG_TOSHIBA is not set CONFIG_MICROCODE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set CONFIG_MTRR=y CONFIG_SMP=y CONFIG_HAVE_DEC_LOCK=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m # CONFIG_PM is not set # CONFIG_ACPI_INTERPRETER is not set # CONFIG_ACPI_S1_SLEEP is not set # CONFIG_APM_IGNORE_USER_SUSPEND is not set # CONFIG_APM_DO_ENABLE is not set # CONFIG_APM_CPU_IDLE is not set # CONFIG_APM_DISPLAY_BLANK is not set # CONFIG_APM_RTC_IS_GMT is not set # CONFIG_APM_ALLOW_INTS is not set # CONFIG_APM_REAL_MODE_POWER_OFF is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=y CONFIG_PARPORT_PC=y CONFIG_PARPORT_PC_FIFO=y # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play configuration # CONFIG_PNP=y # CONFIG_ISAPNP is not set # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=m # CONFIG_BLK_DEV_NBD is not set CONFIG_BLK_DEV_RAM=m CONFIG_BLK_DEV_RAM_SIZE=16386 # # Multi-device support (RAID and LVM) # CONFIG_MD=y # CONFIG_BLK_DEV_MD is not set CONFIG_BLK_DEV_LVM=m CONFIG_LVM_PROC_FS=y # # Networking options # CONFIG_PACKET=m CONFIG_PACKET_MMAP=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y # CONFIG_NETLINK_DEV is not set CONFIG_NETFILTER=y CONFIG_NETFILTER_DEBUG=y CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=y CONFIG_IP_NF_FTP=y # CONFIG_IP_NF_QUEUE is not set CONFIG_IP_NF_IPTABLES=y # CONFIG_IP_NF_MATCH_LIMIT is not set # CONFIG_IP_NF_MATCH_MAC is not set # CONFIG_IP_NF_MATCH_MARK is not set # CONFIG_IP_NF_MATCH_MULTIPORT is not set CONFIG_IP_NF_MATCH_TOS=y CONFIG_IP_NF_MATCH_STATE=y # CONFIG_IP_NF_MATCH_UNCLEAN is not set # CONFIG_IP_NF_MATCH_OWNER is not set CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y # CONFIG_IP_NF_TARGET_MIRROR is not set CONFIG_IP_NF_NAT=y CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=y # CONFIG_IP_NF_TARGET_REDIRECT is not set CONFIG_IP_NF_MANGLE=y # CONFIG_IP_NF_TARGET_TOS is not set # CONFIG_IP_NF_TARGET_MARK is not set CONFIG_IP_NF_TARGET_LOG=y # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set # # # # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set
Re: 3c59x: Using bad IRQ 0
On Thu, 23 Nov 2000, Tobias Ringstrom wrote: > > > > - enable DEBUG in arch/i386/kernel/pci-i386.h. This should make the code > >print out what the pirq table entries are etc. > > Done. When adding the call to eisa_set_level_irq, the line > > IRQ for 00:0a.0(0) via 00:0a.0 -> PIRQ 03, mask 1eb8, excl -> newirq=9 -> >assigning IRQ 9 ... OK > > was changed into > > IRQ for 00:0a.0(0) via 00:0a.0 -> PIRQ 03, mask 1eb8, excl -> newirq=9 -> >assigning IRQ 9 -> edge ... OK Ok. The thing was marked as edge-triggered, which is basically always wrong for a PCI interrupt. The above printout just means that it now noticed that it was edge, and fixed it up in the ELCR. > > - add the line "eisa_set_level_irq(irq);" to pirq_via_set() just before > >the "return 1;" > > You certainly know your kernel very well... :-) That's why they pay me the big bucks. Good. I'll make it do the eisa_set_level_irq() in the generic code: it should always be right (we don't do it now in the PIIX4 case, for example, but the PIIX documentation actually says that we _should_), and there is no need to do it separately for each interrupt router. One down. Now just tell me if the problem with the machine that needs warm-booting from Windows is fixed by the other PCI change, and I'll be a happy camper. (Or rather, I'd be a happy camper if I knew what the cause of the disk corruption reports is. That one bugs me). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Cardbus bridge problems
On Thu, 23 Nov 2000, Linus Torvalds wrote: > Tobias? Does changing that if-statement that make your bus happier? I'll try this tomorrow. The sick laptop is at work, and I'm home. The time difference really slows things down. :-( /Tobias - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PCI id list update
[Martin Dalecki] > Just a small trivial obviously correct update... OK, merged into my pending pci_ids.h patch. (This is bigger than necessary because I converted almost all spaces to tabs.) Peter --- 2.4.0test11/include/linux/pci_ids.h.bak Mon Nov 13 01:43:49 2000 +++ 2.4.0test11/include/linux/pci_ids.h Thu Nov 23 12:17:07 2000 @@ -191,8 +191,8 @@ #define PCI_VENDOR_ID_NS 0x100b #define PCI_DEVICE_ID_NS_87415 0x0002 -#define PCI_DEVICE_ID_NS_87560_LIO 0x000e -#define PCI_DEVICE_ID_NS_87560_USB 0x0012 +#define PCI_DEVICE_ID_NS_87560_LIO 0x000e +#define PCI_DEVICE_ID_NS_87560_USB 0x0012 #define PCI_DEVICE_ID_NS_87410 0xd001 #define PCI_VENDOR_ID_TSENG0x100c @@ -254,9 +254,17 @@ #definePCI_DEVICE_ID_IBM_405GP 0x0156 #define PCI_DEVICE_ID_IBM_MPIC_2 0x +#define PCI_VENDOR_ID_COMPEX2 0x101a // pci.ids says "AT GIS (NCR)" +#define PCI_DEVICE_ID_COMPEX2_100VG0x0005 + #define PCI_VENDOR_ID_WD 0x101c #define PCI_DEVICE_ID_WD_7197 0x3296 +#define PCI_VENDOR_ID_AMI 0x101e +#define PCI_DEVICE_ID_AMI_MEGARAID30x1960 +#define PCI_DEVICE_ID_AMI_MEGARAID 0x9010 +#define PCI_DEVICE_ID_AMI_MEGARAID20x9060 + #define PCI_VENDOR_ID_AMD 0x1022 #define PCI_DEVICE_ID_AMD_LANCE0x2000 #define PCI_DEVICE_ID_AMD_LANCE_HOME 0x2001 @@ -272,6 +280,8 @@ #define PCI_DEVICE_ID_AMD_VIPER_740C 0x740C #define PCI_VENDOR_ID_TRIDENT 0x1023 +#define PCI_DEVICE_ID_TRIDENT_4DWAVE_DX0x2000 +#define PCI_DEVICE_ID_TRIDENT_4DWAVE_NX0x2001 #define PCI_DEVICE_ID_TRIDENT_9320 0x9320 #define PCI_DEVICE_ID_TRIDENT_9388 0x9388 #define PCI_DEVICE_ID_TRIDENT_9397 0x9397 @@ -298,10 +308,10 @@ #define PCI_DEVICE_ID_MATROX_MIL_2 0x051b #define PCI_DEVICE_ID_MATROX_MIL_2_AGP 0x051f #define PCI_DEVICE_ID_MATROX_MGA_IMP 0x0d10 -#define PCI_DEVICE_ID_MATROX_G100_MM0x1000 -#define PCI_DEVICE_ID_MATROX_G100_AGP 0x1001 -#define PCI_DEVICE_ID_MATROX_G200_PCI 0x0520 -#define PCI_DEVICE_ID_MATROX_G200_AGP 0x0521 +#define PCI_DEVICE_ID_MATROX_G100_MM 0x1000 +#define PCI_DEVICE_ID_MATROX_G100_AGP 0x1001 +#define PCI_DEVICE_ID_MATROX_G200_PCI 0x0520 +#define PCI_DEVICE_ID_MATROX_G200_AGP 0x0521 #definePCI_DEVICE_ID_MATROX_G400 0x0525 #define PCI_DEVICE_ID_MATROX_VIA 0x4536 @@ -365,8 +375,8 @@ #define PCI_DEVICE_ID_PCTECH_SAMURAI_1 0x3010 #define PCI_DEVICE_ID_PCTECH_SAMURAI_IDE 0x3020 -#define PCI_VENDOR_ID_DPT 0x1044 -#define PCI_DEVICE_ID_DPT 0xa400 +#define PCI_VENDOR_ID_DPT 0x1044 +#define PCI_DEVICE_ID_DPT 0xa400 #define PCI_VENDOR_ID_OPTI 0x1045 #define PCI_DEVICE_ID_OPTI_92C178 0xc178 @@ -380,6 +390,10 @@ #define PCI_DEVICE_ID_OPTI_82C861 0xc861 #define PCI_DEVICE_ID_OPTI_82C825 0xd568 +#define PCI_VENDOR_ID_ELSA 0x1048 +#define PCI_DEVICE_ID_ELSA_QS1000 0x1000 +#define PCI_DEVICE_ID_ELSA_QS3000 0x3000 + #define PCI_VENDOR_ID_SGS 0x104a #define PCI_DEVICE_ID_SGS_2000 0x0008 #define PCI_DEVICE_ID_SGS_1764 0x0009 @@ -406,6 +420,8 @@ #define PCI_DEVICE_ID_TI_1251B 0xac1f #define PCI_DEVICE_ID_TI_1420 0xac51 +#define PCI_VENDOR_ID_SONY 0x104d +#define PCI_DEVICE_ID_SONY_CXD3222 0x8039 #define PCI_VENDOR_ID_OAK 0x104e #define PCI_DEVICE_ID_OAK_OTI107 0x0107 @@ -503,9 +519,10 @@ #define PCI_VENDOR_ID_LEADTEK 0x107d #define PCI_DEVICE_ID_LEADTEK_805 0x -#define PCI_VENDOR_ID_INTERPHASE 0x107e +#define PCI_VENDOR_ID_INTERPHASE 0x107e #define PCI_DEVICE_ID_INTERPHASE_5526 0x0004 #define PCI_DEVICE_ID_INTERPHASE_55x6 0x0005 +#define PCI_DEVICE_ID_INTERPHASE_5575 0x0008 #define PCI_VENDOR_ID_CONTAQ 0x1080 #define PCI_DEVICE_ID_CONTAQ_82C5990x0600 @@ -544,8 +561,8 @@ #define PCI_VENDOR_ID_BROOKTREE0x109e #define PCI_DEVICE_ID_BROOKTREE_8480x0350 #define PCI_DEVICE_ID_BROOKTREE_849A 0x0351 -#define PCI_DEVICE_ID_BROOKTREE_878_1 0x036e -#define PCI_DEVICE_ID_BROOKTREE_878 0x0878 +#define PCI_DEVICE_ID_BROOKTREE_878_1 0x036e +#define PCI_DEVICE_ID_BROOKTREE_8780x0878 #define PCI_DEVICE_ID_BROOKTREE_8474 0x8474 #define PCI_VENDOR_ID_SIERRA 0x10a8 @@ -617,6 +634,7 @@ #define PCI_DEVICE_ID_AL_M5229 0x5229 #define PCI_DEVICE_ID_AL_M5237 0x5237 #define PCI_DEVICE_ID_AL_M5243 0x5243 +#define PCI_DEVICE_ID_AL_M5451 0x5451 #define PCI_DEVICE_ID_AL_M7101 0x7101 #define PCI_VENDOR_ID_MITSUBISHI 0x10ba @@ -624,7 +642,7 @@ #define PCI_VENDOR_ID_SURECOM 0x10bd #define PCI_DEVICE_ID_SURECOM_NE34 0x0e34 -#define PCI_VENDOR_ID_NEOMAGIC 0x10c8 +#define PCI_VENDOR_ID_NEOMAGIC 0x10c8 #define
Re: silly [< >] and other excess
Albert D. Cahalan writes: > > they are not only references to > > kernel functions, but also kernel data and read only data within > > the kernel text segment. > > 1. this is harmless > 2. this is useful (you might get a variable's name) Wrong. Op-codes on this machine are organised such that bits 31-28 indicate the "condition" that the instruction executes. All 16 combinations are meaningful. This means that any 32-bit value can appear to be an instruction OR data. It takes human intellect to decide which it is. No machine can tell you that. > Nope. You get the unmolested oops and some symbol data. > If there isn't any symbol for 0x424a5149, so what? It is > no big deal to look up a few opcodes in the symbol table > by accident. But there could well be a symbol for 0xc0023004, but it also corresponds to the instruction: andgt r3, r2, r4 "Perform a logical AND operation between r2 and r4 and place the result in r3 if the condition codes indicate the `Greater Than' condition" In addition, the kernel may not be compiled to run at address 0xC... but at address 0x6... or maybe even 0xe... Guess what 0xE means in the high nibble of the op-code? "Always", or "Unconditional". > That would be trading one design flaw for another. > > The hard part of klogd/ksymoops is decoding the code bytes AFAIK. > The rest is a just a cross between grep and ps -- you search and > you do symbol lookups. I could throw it together in a few hours, > minus the disassembly part. As far as I am concerned, you are the people who propose to break something, and therefore you are the people who should provide the effort to fix what you will be breaking when the brokenness is highlighted. _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: silly [< >] and other excess
Ragnar Hojland Espinosa writes: > On Thu, Nov 23, 2000 at 12:26:30AM +, Russell King wrote: > > Oh, missed this one. Here you're wrong again. The numbers in [< >] > > should be looked up, and no others. The code can look exactly like > > a kernel address. In this case you definitely do NOT want to have > > them converted. > > Okay. How about just using some prefix to the hex number, such as '>'? > It'll still save plenty of space, and would be trivial changes for the > tools. That is more a question for Keith Owens, not me. Keith is the maintainer of ksymoops. He has to be happy with the address highlighting. I just have to be happy that we don't loose ksymoops. _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 3c59x: Using bad IRQ 0
On Thu, 23 Nov 2000, Linus Torvalds wrote: > > > Tobias, can you confirm that calling pci_enable_device before reading > > > dev->irq fixes the 3c59x.c problem for you? > > > > Nope. The interrupts do not seem to get through. Packets are transmitted, > > but that's it. I've copied the interesting parts from dmesg: > > > > 3c59x.c:LK1.1.11 13 Nov 2000 Donald Becker and others. >http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $ > > See Documentation/networking/vortex.txt > > PCI: Enabling device 00:0a.0 (0014 -> 0017) > > PCI: Assigned IRQ 9 for device 00:0a.0 > > eth0: 3Com PCI 3c905C Tornado at 0xa400, 00:01:02:b4:18:e4, IRQ 9 > > Ok, the VIA stuff is happy, and enables the irq routing. The fact that the > irq's don't actually seem to ever actually appear means that the enable > sequence is probably slightly buggy. > > Can you do two things? > > - enable DEBUG in arch/i386/kernel/pci-i386.h. This should make the code >print out what the pirq table entries are etc. Done. When adding the call to eisa_set_level_irq, the line IRQ for 00:0a.0(0) via 00:0a.0 -> PIRQ 03, mask 1eb8, excl -> newirq=9 -> assigning IRQ 9 ... OK was changed into IRQ for 00:0a.0(0) via 00:0a.0 -> PIRQ 03, mask 1eb8, excl -> newirq=9 -> assigning IRQ 9 -> edge ... OK > - add the line "eisa_set_level_irq(irq);" to pirq_via_set() just before >the "return 1;" You certainly know your kernel very well... :-) That did the trick, and the 3Com card works just fine. Now the only question is why this happened, but I leave that in you capable hands. /Tobias Linux version 2.4.0-test11 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #29 Thu Nov 23 18:58:29 CET 2000 BIOS-provided physical RAM map: BIOS-e820: 0009e800 @ (usable) BIOS-e820: 1800 @ 0009e800 (reserved) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 0feec000 @ 0010 (usable) BIOS-e820: 3000 @ 0ffec000 (ACPI data) BIOS-e820: 0001 @ 0ffef000 (reserved) BIOS-e820: 1000 @ 0000 (ACPI NVS) BIOS-e820: 0001 @ (reserved) On node 0 totalpages: 65516 zone(0): 4096 pages. zone(1): 61420 pages. zone(2): 0 pages. Kernel command line: BOOT_IMAGE=linux ro root=303 BOOT_FILE=/boot/vmlinuz ide=reverse 1 ide_setup: ide=reverse : Enabled support for IDE inverse scan order. Initializing CPU#0 Detected 1009.006 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 2011.96 BogoMIPS Memory: 255116k/262064k available (1624k kernel code, 6556k reserved, 101k data, 220k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Before vendor init, caps: 0183f9ff c1c7f9ff , vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After vendor init, caps: 0183f9ff c1c7f9ff CPU: After generic, caps: 0183f9ff c1c7f9ff CPU: Common caps: 0183f9ff c1c7f9ff CPU: AMD Athlon(tm) Processor stepping 02 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel PCI: BIOS32 Service Directory structure at 0xc00f92a0 PCI: BIOS32 Service Directory entry at 0xf0ef0 PCI: BIOS probe returned s=00 hw=11 ver=02.10 l=01 PCI: PCI BIOS revision 2.10 entry at 0xf10f0, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: IDE base address fixup for 00:04.1 PCI: Scanning for ghost devices on bus 0 PCI: Scanning for ghost devices on bus 1 Unknown bridge resource 0: assuming transparent PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00f16c0 00:0c slot=01 0:01/1eb8 1:02/1eb8 2:03/1eb8 3:05/1eb8 00:0b slot=02 0:02/1eb8 1:03/1eb8 2:05/1eb8 3:01/1eb8 00:0a slot=03 0:03/1eb8 1:05/1eb8 2:01/1eb8 3:02/1eb8 00:09 slot=04 0:05/1eb8 1:01/1eb8 2:02/1eb8 3:03/1eb8 00:0d slot=05 0:05/1eb8 1:01/1eb8 2:02/1eb8 3:03/1eb8 00:04 slot=00 0:01/1eb8 1:02/1eb8 2:03/1eb8 3:05/1eb8 00:01 slot=00 0:01/1eb8 1:02/1eb8 2:03/1eb8 3:05/1eb8 00:11 slot=00 0:02/1eb8 1:03/1eb8 2:05/1eb8 3:01/1eb8 00:12 slot=00 0:01/1eb8 1:02/1eb8 2:03/1eb8 3:05/1eb8 PCI: Using IRQ router VIA [1106/0686] at 00:04.0 PCI: IRQ fixup 00:0a.0: ignoring bogus IRQ 255 00:0b.0: ignoring bogus IRQ 255 IRQ for 00:0a.0(0) via 00:0a.0 -> PIRQ 03, mask 1eb8, excl ... failed IRQ for 00:0b.0(0) via 00:0b.0 -> PIRQ 02, mask 1eb8, excl -> got IRQ 10 PCI: Found IRQ 10 for device 00:0b.0 PCI: The same IRQ used for device 00:11.0 PCI: Allocating resources PCI: Resource e000-e7ff (f=1208, d=0, p=0) PCI: Resource d800-d80f (f=101, d=0, p=0)
Re: PROBLEM: Cruft mounting option incorrect in ISOFS code
Rogier Wolff wrote: > > Alan Cox wrote: > > > under 1 gig in size. You can exhibit the problem by mounting the dvd movie > > > "The World is Not Enough" as it contains a video_ts.vob which is larger than > > > 1 gigabyte. You will see that most of the file lengths are incorrect due to > > > the "cruft mounting option" hacking off the high order byte. There are > > > certainly many more movies out there that exhibit this problem so it would > > > be a good thing for someone to fix. > > > The cruft thing is correct in itself. The size being 4Gb is trivial > > to change providing someone can provide a reference to the standards > > that say its ok. So is the limit 4Gig, who documents it ? > > Page 137 of DVD Demystified by Jim Taylor says: > > - Individual files must be less than or equal to 1 gigabyte in length. The maximum size of a single UDF extent is 2^30-1 For DVD Video, the data of each file shall be recorded in a single extent. So thats where the limit comes from :) Ben -- Linux UDF - http://linux-udf.sourceforge.net Latest Is - udf-0.9.2.1 (http://www.csc.calpoly.edu/~bfennema/udf.html) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: {PATCH} isofs stuff
On Thu, Nov 23, 2000 at 09:20:15AM -0800, Linus Torvalds wrote: > Can you check whether the single patch of _just_ removing the extra "f_pos > >= i_size" test in do_isofs_readdir() fixes it? The other changes of > Andries patch look like they should not affect code generation at all, but > I'd still like to verify that it's only that part. If so, it definitely Verified, it does. -- /| Ragnar Højland Freedom - Linux - OpenGL Fingerprint 94C4B \ o.O| 2F0D27DE025BE2302C =(_)= "Thou shalt not follow the NULL pointer for 104B78C56 B72F0822 U chaos and madness await thee at its end." hkp://keys.pgp.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Cardbus bridge problems
[ Tobias: thanks for an excellent report, btw ] On Wed, 22 Nov 2000, Tobias Ringstrom wrote: > On Wed, 22 Nov 2000, Tobias Ringstrom wrote: > > > Not that I like it, but I need to boot Win98, and then warm boot into > > Linux, or the Cardbus is not working. This is using Linux-2.4.0-test11 on > > a Mitac 7233 laptop. > > > > Using lspci, I can see that the secondary and subordinate busses of the > > Cardbus bridges are unconfigured/incorrect. I have attached dmesg and > > lspci -vvvxxx output from the two cases (ok=Win98+warm-boot and > > fail=cold-boot). I have enabled all PCI debug things I could find. Bw, it > > would be really nice to have ONE place to enable the PCI debug info. You have a really sick system, the following is absolute garbage: 00:08.0 CardBus bridge: Texas Instruments PCI1225 (rev 01) Subsystem: Mitac: Unknown device 7233 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset+ 16bInt+ PostWrite+ 16-bit legacy interface ports at 0001 That bus setup is horribly wrong, and says that the CardBus bridge no bus numbers, which is obviously not correct. It somehow got through the bridge scanning without being fixed up.. Now, the reason for why it seems to be so unhappy is apparently Scanning behind PCI bridge 00:08.0, config 40, pass 1 Scanning behind PCI bridge 00:08.1, config 40, pass 1 Note the "config 40". It basically seems to imply that the cardbus bridge has been set up as bus 0x40, ie 64. With no secondary bus behind it. Which looks completely and utterly bogus. I bet the thing works for you if you change the magic constant 0xff in pci_scan_bridge() to the new magic constant 0x00. Basically, we don't much care what it reports for the primary bus number: but we _do_ care that a PCI bridge should have a secondary bus number. Martin, What say you? I think 0x00 makes more sense here anyway. And I bet(*) it will also fix the problem Tobias is seeing. Tobias? Does changing that if-statement that make your bus happier? Oh, btw, Martin: I suspect the "cardbus bridge already set up" case in pci_scan_bridge() should also have the logic unsigned int cmax = child->subordinate; if (cmax > max) max = cmax; in addition to setting up the resources. Comments? As it stands now, it looks like a pre-configured cardbus bridge doesn't count towards "max" at all.. Linus (*) But I won't be betting huge amounts of money on it. There may be other things that aren't initialized correctly. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: {PATCH} isofs stuff
On Thu, 23 Nov 2000, Linus Torvalds wrote: > To tie two threads together again: the thread about FS corruption is one > of my main worries right now. Do people who see this happen to use a gcc > other than egcs-2.91.66? I know Andries apparently has 2.95.2, and he's > one of the people who have reported corruption problems... I am using 2.91.66. Ok, I'll get on with testing Al Viro's latest patch now. Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: {PATCH} isofs stuff
On Thu, 23 Nov 2000, Ragnar Hojland Espinosa wrote: > > Yup, indeed it solves the dir/namei problem. Can you check whether the single patch of _just_ removing the extra "f_pos >= i_size" test in do_isofs_readdir() fixes it? The other changes of Andries patch look like they should not affect code generation at all, but I'd still like to verify that it's only that part. If so, it definitely looks like a gcc-2.95.2 code generation bug - that single if() statement does not actually matter for the end result, it's just a (misguided) early-out optimization. [ Btw, looking at the generated assembly is quite painful. Ugh. It reminds me again why "long long" is to be avoided with gcc. Getting rid of the extra test actually improves and speeds up that function probably simply because the 64-bit arithmetic just cofuses gcc so badly. ] Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ext2 filesystem corruptions back from dead? 2.4.0-test11
On Thu, 23 Nov 2000, Alexander Viro wrote: > On Thu, 23 Nov 2000, Neil Brown wrote: > > > which enabled ext2_notify_change, however ext2_notify_change has a > > bug. > > It sets attributes from iattr->ia_attr_flags even > > if ATTR_ATTR_FLAG is NOT SET in iattr->ia_valid. > > Arrrgh. Could you try that: OK, I really need more coffee - wrong patch. My apologies. Correct (OK, intended) one follows: diff -urN rc11/fs/buffer.c rc11-ext2/fs/buffer.c --- rc11/fs/buffer.cMon Nov 20 01:18:59 2000 +++ rc11-ext2/fs/buffer.c Tue Nov 21 01:14:34 2000 @@ -1527,6 +1527,15 @@ } return 0; out: + bh = head; + do { + if (buffer_new(bh) && !buffer_uptodate(bh)) { + memset(bh->b_data, 0, bh->b_size); + set_bit(BH_Uptodate, >b_state); + mark_buffer_dirty(bh); + } + bh = bh->b_this_page; + } while (bh != head); return err; } diff -urN rc11/fs/ext2/file.c rc11-ext2/fs/ext2/file.c --- rc11/fs/ext2/file.c Wed Oct 4 03:44:54 2000 +++ rc11-ext2/fs/ext2/file.cTue Nov 21 01:14:34 2000 @@ -25,17 +25,6 @@ static loff_t ext2_file_lseek(struct file *, loff_t, int); static int ext2_open_file (struct inode *, struct file *); -#define EXT2_MAX_SIZE(bits)\ - (((EXT2_NDIR_BLOCKS + (1LL << (bits - 2)) + \ - (1LL << (bits - 2)) * (1LL << (bits - 2)) + \ - (1LL << (bits - 2)) * (1LL << (bits - 2)) * (1LL << (bits - 2))) * \ - (1LL << bits)) - 1) - -static long long ext2_max_sizes[] = { -0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -EXT2_MAX_SIZE(10), EXT2_MAX_SIZE(11), EXT2_MAX_SIZE(12), EXT2_MAX_SIZE(13) -}; - /* * Make sure the offset never goes beyond the 32-bit mark.. */ @@ -56,7 +45,7 @@ if (offset<0) return -EINVAL; if (((unsigned long long) offset >> 32) != 0) { - if (offset > ext2_max_sizes[EXT2_BLOCK_SIZE_BITS(inode->i_sb)]) + if (offset >= inode->i_sb->u.ext2_sb.s_max_size) return -EINVAL; } if (offset != file->f_pos) { @@ -110,4 +99,5 @@ struct inode_operations ext2_file_inode_operations = { truncate: ext2_truncate, + setattr:ext2_notify_change, }; diff -urN rc11/fs/ext2/inode.c rc11-ext2/fs/ext2/inode.c --- rc11/fs/ext2/inode.cWed Oct 4 03:44:54 2000 +++ rc11-ext2/fs/ext2/inode.c Thu Nov 23 14:52:17 2000 @@ -153,11 +153,13 @@ * This function translates the block number into path in that tree - * return value is the path length and @offsets[n] is the offset of * pointer to (n+1)th node in the nth one. If @block is out of range - * (negative or too large) warning is printed and zero returned. + * (negative or too large) we return zero. Warning is printed if @block + * is negative - that should never happen. Too large value is OK, it + * just means that ext2_get_block() should return -%EFBIG. * * Note: function doesn't find node addresses, so no IO is needed. All * we need to know is the capacity of indirect blocks (taken from the - * inode->i_sb). + * @inode->i_sb). */ /* @@ -196,7 +198,7 @@ offsets[n++] = (i_block >> ptrs_bits) & (ptrs - 1); offsets[n++] = i_block & (ptrs - 1); } else { - ext2_warning (inode->i_sb, "ext2_block_to_path", "block > big"); + /* Too large, nothing to do here */ } return n; } @@ -216,7 +218,7 @@ * i.e. little-endian 32-bit), chain[i].p contains the address of that * number (it points into struct inode for i==0 and into the bh->b_data * for i>0) and chain[i].bh points to the buffer_head of i-th indirect - * block for i>0 and NULL for i==0. In other words, it holds the block + * block for i>0 and %NULL for i==0. In other words, it holds the block * numbers of the chain, addresses they were taken from (and where we can * verify that chain did not change) and buffer_heads hosting these * numbers. @@ -230,11 +232,11 @@ * or when it reads all @depth-1 indirect blocks successfully and finds * the whole chain, all way to the data (returns %NULL, *err == 0). */ -static inline Indirect *ext2_get_branch(struct inode *inode, - int depth, - int *offsets, - Indirect chain[4], - int *err) +static Indirect *ext2_get_branch(struct inode *inode, +int depth, +int *offsets, +Indirect chain[4], +int *err) { kdev_t dev = inode->i_dev; int size = inode->i_sb->s_blocksize; @@ -505,7 +507,7 @@
Re: 3c59x: Using bad IRQ 0
On Tue, 21 Nov 2000, Tobias Ringstrom wrote: > > > > Tobias, can you confirm that calling pci_enable_device before reading > > dev->irq fixes the 3c59x.c problem for you? > > Nope. The interrupts do not seem to get through. Packets are transmitted, > but that's it. I've copied the interesting parts from dmesg: > > 3c59x.c:LK1.1.11 13 Nov 2000 Donald Becker and others. >http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $ > See Documentation/networking/vortex.txt > PCI: Enabling device 00:0a.0 (0014 -> 0017) > PCI: Assigned IRQ 9 for device 00:0a.0 > eth0: 3Com PCI 3c905C Tornado at 0xa400, 00:01:02:b4:18:e4, IRQ 9 Ok, the VIA stuff is happy, and enables the irq routing. The fact that the irq's don't actually seem to ever actually appear means that the enable sequence is probably slightly buggy. Can you do two things? - enable DEBUG in arch/i386/kernel/pci-i386.h. This should make the code print out what the pirq table entries are etc. - add the line "eisa_set_level_irq(irq);" to pirq_via_set() just before the "return 1;" Jeff, you had complete VIA docs, right? Can you check that whatever Tobias' ends up having output from the debug stuff looks sane? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: "Hyper-Mount" option possible???
Followup to: <[EMAIL PROTECTED]> By author:Robert L Martin <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Not on list just throwing an idea out. > One thing that "bugs" me is if a given drive has more than one partion > each partion has to be mounted seperatly. > With CDs this also means you can not mount "split" cds in full if you > want to. Soo Given that Super-Mount is already taken, How about (in > 2.5??) hashing out a Hypermount option. > The way it could work is if you mount a full drive say "hdd" and have > each partion mounted on a tree from the mount point > of the drive. > This sounds a lot like cdfs. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: {PATCH} isofs stuff
On Thu, Nov 23, 2000 at 04:50:22AM +0100, [EMAIL PROTECTED] wrote: > Below a working patch for which the isofs images I got > all are OK. (There is still a lot of silliness here - > superfluous parentheses, a rename of isofs_cmp to isofs_comp > in one file to avoid confusion with the isofs_cmp in another file..) Yup, indeed it solves the dir/namei problem. However, while my ide drive is fine, my mistumi (mcdx) still oopses and/or aaies when doing dd on it. Here's what I was able to catch from the trace.. doesn't look too relevant, tho. I tried oopisng it again, but it spew a list of hex addresses as long as my arm and couldn't catch the first one. __wake_up ce-28 0xe3c9d34d handle_scancode del_timer handle_scancode do_SAK vc_resize Where __wake_up: c0113f95: 89 15 4c 01 22 c0 movl %edx,0xc022014c c0113f9b: ff 05 44 c4 25 c0 incl 0xc025c444 c0113fa1: 89 d8 movl %ebx,%eax c0113fa3: e8 10 fa ff ff call c01139b8 c0113fa8: 57 pushl %edi c0113fa9: 9d popf c0113faa: 8b 4d f8movl 0xfff8(%ebp),%ecx c0113fad: 23 4e 00andl 0x0(%esi),%ecx c0113fb0: f6 c1 01testb $0x1,%cl c0113fb3: 75 43 jnec0113ff8 <__wake_up+0xd0> c0113fb5: 8b 45 e8movl 0xffe8(%ebp),%eax c0113fb8: 39 45 e4cmpl %eax,0xffe4(%ebp) c0113fbb: 74 3b je c0113ff8 <__wake_up+0xd0> c0113fbd: 8b 75 e4movl 0xffe4(%ebp),%esi c0113fc0: 8b 55 e4movl 0xffe4(%ebp),%edx c0113fc3: 83 c6 f8addl $0xfff8,%esi c0113fc6: 8b 12 movl (%edx),%edx c0113fc8: 89 55 e4movl %edx,0xffe4(%ebp) c0113fcb: 8b 5e 04movl 0x4(%esi),%ebx >>> c0113fce: 8b 03 movl (%ebx),%eax c0113fd0: 85 45 fctestl %eax,0xfffc(%ebp) c0113fd3: 74 e0 je c0113fb5 <__wake_up+0x8d> c0113fd5: 83 7d f4 00 cmpl $0x0,0xfff4(%ebp) c0113fd9: 74 96 je c0113f71 <__wake_up+0x49> c0113fdb: 8b 4d f8movl 0xfff8(%ebp),%ecx c0113fde: 23 4e 00andl 0x0(%esi),%ecx -- /| Ragnar Højland Freedom - Linux - OpenGL Fingerprint 94C4B \ o.O| 2F0D27DE025BE2302C =(_)= "Thou shalt not follow the NULL pointer for 104B78C56 B72F0822 U chaos and madness await thee at its end." hkp://keys.pgp.com Handle via comment channels only. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: kernel 2.4.0-test11-ac1 hang with usb-uhci and emu10k1
On Thu, Nov 23, 2000 at 04:35:33PM +, Rui Sousa wrote: > On Thu, 23 Nov 2000, Michael Elkins wrote: > > Usb controller is sharing a interrupt with the emu10k1. > For what I know the emu10k1 driver doesn't have any problem > sharing irq's, so I would blame the usb driver... usb-uhci doesn't also have any problem with sharing irqs: > cat /proc/interrupts 10:5597981 XT-PIC aic7xxx, eth0, usb-uhci Hm, no one left to blame... I would debug it as follows: Place various printks in the initialization code (reset_hc(), start_hc() and alloc_uhci) and find out after which printk it hangs. Then it would be possible to investigate this further... -- Georg Acher, [EMAIL PROTECTED] http://www.in.tum.de/~acher/ "Oh no, not again !" The bowl of petunias - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] silly [< >] and other excess
[Alan Cox] > > Thats because too many things get put on a line then. > > And because we do [] [] not [][] ? [Andries Brouwer] > In the good old times we had foo bar for a total of 8*(8+1) = 72 > positions. Now we have [] [] which takes 8*(8+1+4) = 104 I've got it! Put multiple addresses within one set of [< >]. ksymoops and klogd will require a small adjustment, of course. The following show_stack() is 8 addrs per line, 79 columns. Comments? Peter --- arch/i386/kernel/traps.c.orig Mon Nov 13 01:44:02 2000 +++ arch/i386/kernel/traps.cThu Nov 23 10:10:06 2000 @@ -126,7 +126,6 @@ printk("%08lx ", *stack++); } - printk("\nCall Trace: "); stack = esp; i = 1; module_start = VMALLOC_START; @@ -144,12 +143,17 @@ if (((addr >= (unsigned long) &_stext) && (addr <= (unsigned long) &_etext)) || ((addr >= module_start) && (addr <= module_end))) { - if (i && ((i % 8) == 0)) - printk("\n "); - printk("[<%08lx>] ", addr); + if (i==1) + printk("\nCall Trace: [<"); + else if ((i % 8)==0) + printk(">]\n[<"); + else + printk(" "); + printk("%08lx", addr); i++; } } + printk(">]\n"); } static void show_registers(struct pt_regs *regs) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/