[UPDATE] Zerocopy against 2.4.3-pre4
Available at: ftp://ftp.kernel.org/pub/linux/kernel/people/davem/zerocopy-2.4.3p3-1.diff.gz This is basically identical to the networking in Alan's current patches. It is only provided for people who want the zerocopy stuff but for some reason don't feel like getting all the other changes in Alan's tree :-))) Please report any regressions found vs. 2.4.3-pre4 vanilla, thanks. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE poweroff -> hangup
Andre Hedrick writes: >On Thu, 15 Mar 2001, CODEZ wrote: >> ide_dmaproc: chipset supported ide_dma_timeout func only: 14 >> I have ASUS 440BX/F mb with intel PIIX4 chipset.. > >All of the 440*X Chipsets using a PIIX4/PIIX4AB/PIIX4EB are broken beyond >repair. Well, that may be so; but I get the same error -- *precisely* the same error! -- on an SiS motherboard that quite clearly lacks a PIIX4: # lspci 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 530 Host (rev 02) 00:00.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0) 00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513 (rev b1) 00:01.1 Class ff00: Silicon Integrated Systems [SiS] ACPI 00:01.2 USB Controller: Silicon Integrated Systems [SiS] 7001 (rev 11) 00:02.0 PCI bridge: Silicon Integrated Systems [SiS] 5591/5592 AGP 00:0b.0 Ethernet controller: 3Com Corporation 3c900 10BaseT [Boomerang] 01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 6306 3D-AGP (rev a2) # lspci -v -s0:0 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 530 Host (rev 02) Flags: bus master, medium devsel, latency 32 Memory at e000 (32-bit, non-prefetchable) Capabilities: [c0] AGP version 2.0 00:00.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0) (prog-if 8a [Master SecP PriP]) Subsystem: Silicon Integrated Systems [SiS] SiS5513 EIDE Controller (A,B step) Flags: bus master, fast devsel, latency 128, IRQ 14 I/O ports at e400 I/O ports at e000 I/O ports at d800 I/O ports at d400 I/O ports at d000 So... Any ideas? > I will pop a nasty patch to get you through the almost death, but it > is nasty and not the preferred unknow solution. I await your fugly patch with bated breath and baited fishook. -- Chip Salzenberga.k.a.<[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
How to optimize routing performance
I've performed a test on the routing capacity of a Linux 2.4.2 box versus a FreeBSD 4.2 box. I used two Pentium Pro 200Mhz computers with 64Mb memory, and two DEC 100Mbit ethernet cards. I used a Smartbits test-tool to measure the packet throughput and the packet size was set to 64 bytes. Linux dropped no packets up to about 27000 packets/s, but then it started to drop packets at higher rates. Worse yet, the output rate actually decreased, so at the input rate of 4 packets/s almost no packets got through. The behaviour of FreeBSD was different, it showed a steadily increased output rate up to about 7 packets/s before the output rate decreased. (Then the output rate was apprx. 4 packets/s). I have not made any special optimizations, aside from not having any background processes running. So, my question is: are these figures true, or is it possible to optimize the kernel somehow? The only changes I have made to the kernel config was to disable advanced routing. Thanks, Mårten - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] New files on read only NFS mount
On Mon, Mar 12, 2001 at 03:56:20PM +0100, Trond Myklebust wrote: > > " " == Chris Jensen <[EMAIL PROTECTED]> writes: > > >> Details please, the minimum info required being 'which kernel > >> is your client running'? > >> > > > Oh yeah, whoops, sorry The server is a 586 and the client is > > 686. They're both using nfs-utils 0.2.1, under linux 2.4.0 > > with NFS v3 enabled, with glibc 2.2.1 The pertinent line in > > /etc/exports is / 192.168.0.1(rw,no_root_squash) > > How does the following patch work out? > I can duplicate the problem and this patch fixes it. Thanks. H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [RFC] fbdev & power management
>But wouldn't falling back to dummycon prevent the driver specific >suspend/resume calls from working? Or at a minimum, make handling those >calls more complex? Not if suspend/resume are handled on the fbdev driver level. Dummycon would only shutdown fbcon on explict open of /dev/fb. Also note it will be possible to have only a serial console and use /dev/fb by itself. In this case we don't even need dummycon since their is no VT support present. >No, there does not need to be graphical images of the text console -- a >simply text buffer would suffice. See email to Ben. >But what about things like GTKFb and >Embedded QT? They would certainly benefit from having a backup screen >image, right? I do not believe there is any way to determine if the >console is in fact in a 'text' or graphical state. Yes and it would not be hard to do this. I have the basic idea in the email to Ben. As for console in text or graphical state take a look at vt_ioctl.c:vt_ioctl() for KDGETMODE. You get back KD_TEXT or KD_GRAPHICS. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [RFC] fbdev & power management
>>I'd go for a fallback to dummycon. It's of no use to waste power on >>creating graphical images of the text console when asleep. And the >>fallback to dummycon is needed anyway while a fbdev is opened (in >>2.5.x). > >We do already have the backup image since we need to backup & restore the >framebuffer content. What he is talking about is in 2.5.X when you explictly open /dev/fb it will call take_over_console with dummy con. This allows for several things. One is with this approach their is no chance of a conflict between X/DRI and fbdev. Especially when we will have fbdev drivers using DMA internally to preform console operations. For some hardware using DMA is the only way fbdev can work and on some platforms fbcon is the only choice. So things going into /dev/ttyX will not have a chance to interfere with X. The second reason is for security. It is possible to have a program to open /dev/fb and see what is being typed on the fore ground console. I sealed up those holes using the dummy con approach and some test to see if the current process is local. Now for fbcon its simpler. Things get writing to the shadow buffer (vc_screenbuf). When the console gets woken up update_screen is called. While power down the shadow buffer can be written to which is much faster than saving a image of the framebuffer. Of course if you still want to do this such in the case of the X server then copy the image of the framebuffer to regular ram. Then power down /dev/fb using some ioctl calls provide. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: scsi_scan problem.
Bob Frey wrote: > > On Wed, Mar 14, 2001 at 09:35:43PM -0500, Pete Zaitcev wrote: > > 16384 LUNs for Fibre Channel. As you see, scanning is out of the > > question. You must issue REPORT LUNs and fall back on scanning > > if the device reports a check condition. I did that when I worked > Why wait for a check condition? There's an INQUIRY field bit that > indicates whether REPORT LUNs is supported. And I'm all for using it in the 2.5 kernel SCSI stack ;-) -- Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford Please check my web site for aic7xxx updates/answers before e-mailing me about problems - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: scsi_scan problem.
On Wed, Mar 14, 2001 at 09:35:43PM -0500, Pete Zaitcev wrote: > 16384 LUNs for Fibre Channel. As you see, scanning is out of the > question. You must issue REPORT LUNs and fall back on scanning > if the device reports a check condition. I did that when I worked Why wait for a check condition? There's an INQUIRY field bit that indicates whether REPORT LUNs is supported. -- Bob Frey [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [RFC] fbdev & power management
>>So the fbdev drivers would register PM with fbcon, not PCI, correct? > >Either that, or the fbdev would register with PCI (or whatever), _and_ >fbcon would too independently. In that scenario, fbcon would only handle >things like disabling the cursor timer, while fbdev's would handle HW >issues. THe only problem is for fbcon to know that a given fbdev is >asleep, this could be an exported per-fbdev flag, an error code, or >whatever. In this case, fbcon can either buffer text input, or fallback >to the cfb working on the backed up fb image (that last thing can be >handled entirely within the fbdev I guess). Hi! I had to give it some thought. I like to see this handles inside the fbdev driver itself instead of inside fbcon. For 2.5.X it will be possible to use /dev/fb with vgacon. Even better yet it will be possible to use just a serial console and not use a VT but still use /dev/fb. So we will want to to have fbdev doing power management itself. As for handling the cursors I recently purposed a standardize cursor api so X can use it as well via userland and a standard fbcon_cursor can be written. With this api it would be easy to handle suspending and restoring the cursor for fbcon for /dev/fb. As for fbcon knowing when it is asleep. Hum. We could have a flags to tell it to have text data updates to be placed in the shadow buffer (struct vc_datas->vc_screenbuffer) only; MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE poweroff -> hangup
On Thu, 15 Mar 2001, CODEZ wrote: > Ello folkz, > Ummm the same problem I am facing whenevr I try to mount my cdrom. I am > using kernel 2.4.2 ac-18 and yep ofcourse I am not removing my cdrom power > supply.. > I tried hdparm -T and got > ide_dmaproc: chipset supported ide_dma_timeout func only: 14 > I have ASUS 440BX/F mb with intel PIIX4 chipset.. > any suggestion All of the 440*X Chipsets using a PIIX4/PIIX4AB/PIIX4EB are broken beyond repair. Several weeks ago, the old hat and I discussed the issue and after sending him the same docs I have from Intel, we both laugh because the errata clear states "NO FIX" Now after going back to Intel with a puzzled look, I found out why/where/how the breakage exists but the fix is not pretty nor does it retain DMA transfer rates. The hack job is fugly, it ruptures the ISR's the TIMERS and the PCI-DMA space locally, but it is not a fatal barf, but a noisy messy one. I will pop a nasty patch to get you through the almost death, but it is nasty and not the preferred unknow solution. 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
Alexander Viro writes: > On Wed, 14 Mar 2001 [EMAIL PROTECTED] wrote: >>> +o Console Tools # 0.3.3# loadkeys -V >>> +o Mount # 2.10e# mount --version >> >> Concerning mount: (i) the version mentioned is too old, Exactly why? Mere missing features don't make for a required upgrade. Version number inflation should be resisted. >> Concerning Console Tools: maybe kbd-1.05 is uniformly better. >> I am not aware of any reason to recommend the use of console-tools. > > Debian has console-tools with priority:required and kbd > with priority:extra. Take it with Yann Dirson... Both should be "extra". They can be removed from the version script. I'm even one of the few remaining console users. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: poll() behaves differently in Linux 2.4.1 vs. Linux 2.2.14 (POLLHUP)
Alexy wrote: >> Damn, we did not test behaviour on absolutely new >> clean never connected socket... Solaris really may >> return 0 on it. >> >> However, looking from other hand the issue looks as >> absolutely academic and not related to practice in >> any way. Hi, I'm not sure this issue is really that academic. In fact, it's one of those nitty-gritty, annoying details that academics tend to ignore :). Anyway, I'm looking at this from a very pragmatic standpoint. I'd like to minimize the complexity and the number of special cases when trying to support an application on several different platforms. If other popular Unix OS's behave this way I definely understand the reasoning, but it seems that at least Solaris 7 does not... Sure, workarounds exist, but they just complicates things. -jeff __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: O_DSYNC flag for open
fdatasync() is the same as fsync(), in linux. until fdatasync() is implimented (ie, syncs the data only), there's no reason to define O_DSYNC. just use: #ifndef O_DSYNC # define O_DSYNC O_SYNC #endif On Sat, Mar 10, 2001 at 01:03:57PM +0600, Denis Perchine wrote: > one small question... Will O_DSYNC flag be available in Linux? > It is available at least on AIX, and HP-UX. The difference with O_SYNC is the > same as between fsync and fdatasync. -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: scsi_scan problem.
Doug Ledford wrote: > Patches welcomed. The one I sent already works on a fiber channel setup (the > qla2x00 in question is fc and so is the Clariion array it's connected to, no > detrimental side effects from scanning the box) and so I'm not inclined to add > a REPORT LUNs section to the code unless absolutely necessary. Clarification, I think REPORT LUNS support is a 2.5 thing, not a stick it in now thing. -- Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford Please check my web site for aic7xxx updates/answers before e-mailing me about problems - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: magic device renumbering was -- Re: Linux 2.4.2ac20
Hi, The solution is not to go down the path2inst road, that is full of its own traps. You want volume labels via a volume manager (do lvm and raid already do this?) and/or filesystem labels (see e2fslabel). This won't solve all of the ills associated with device instance changes, but it will certainly address the biggest one. skd On Wed, Mar 14, 2001 at 10:36:40AM -0500, John Jasen wrote: > > The problem: > > drivers change their detection schemes; and changes in the kernel can > change the order in which devices are assigned names. > > For example, the DAC960(?) drivers changed their order of > detecting controllers, and I did _not_ have fun, given that the machine in > question had about 40 disks to deal with, spread across two controllers. > > This can create a lot of problems for people upgrading large, production > quality systems -- as, in the worst case, the system won't complete the > boot cycle; or in middle cases, the user/sysadmin is stuck rewriting X > amount of files and trying again; or in small cases, you find out that > your SMC and Intel ethernet cards are reversed, and have to go fix things > ... > > Possible solutions(?): > > Solaris uses an /etc/path_to_inst file, to keep track of device ordering, > et al. > > Maybe we should consider something similar, where a physical device to > logical device map is kept and used to keep things consistent on > kernel/driver changes; device addition/removal, and so forth ... > > I am, of course, open to better solutions. > > -- > -- John E. Jasen ([EMAIL PROTECTED]) > -- In theory, theory and practise are the same. In practise, they aren't. > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
New unaligned-accessed arch flag?
Instead of putting arch-specific ifdefs in drivers, would it be reasonable to add a per-arch flag UNALIGNED_PROFITABLE? Arch-specific ifdefs all over the default rx_copybreak values in net drivers are the example I have in mind, but it seems like it would be good knowledge that can be easily exposed to the rest of the kernel. -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: scsi_scan problem.
Pete Zaitcev wrote: > > > Date: Wed, 14 Mar 2001 21:28:14 -0500 > > From: Doug Ledford <[EMAIL PROTECTED]> > > > A bug report I was charged with fixing (qla2x00 driver doesn't see all luns or > > sees multiple identical luns in different scenarios) was not a bug in the > > qla2x00 driver. [...] > > The bug is that we were detecting offline devices and linking > > them into the device list. > > Why is this a bug? What would happen when I telnet into the > the RAID box and enable my volumes on those LUNs? Then they would be legitimate devices and you would do: echo "scsi-add-single-device a b c d" > /proc/scsi/scsi to add them to the device chain. Before then, they aren't anything (at least not in the case of the Clariion array). > > But, some devices (at least the Clariion raid > > chassis) report luns that don't currently have any device bound to them as > > present but offline. This meant if we truly scanned all luns then we got > > something like 100+ devices on one ID from this chassis when only 1 might be > > valid:-( > > 16384 LUNs for Fibre Channel. As you see, scanning is out of the > question. You must issue REPORT LUNs and fall back on scanning > if the device reports a check condition. I did that when I worked > in Sun Storage with A5000/A3500/T3 arrays couple of years ago. Patches welcomed. The one I sent already works on a fiber channel setup (the qla2x00 in question is fc and so is the Clariion array it's connected to, no detrimental side effects from scanning the box) and so I'm not inclined to add a REPORT LUNs section to the code unless absolutely necessary. -- Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford Please check my web site for aic7xxx updates/answers before e-mailing me about problems - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: scsi_scan problem.
> Date: Wed, 14 Mar 2001 21:28:14 -0500 > From: Doug Ledford <[EMAIL PROTECTED]> > A bug report I was charged with fixing (qla2x00 driver doesn't see all luns or > sees multiple identical luns in different scenarios) was not a bug in the > qla2x00 driver. [...] > The bug is that we were detecting offline devices and linking > them into the device list. Why is this a bug? What would happen when I telnet into the the RAID box and enable my volumes on those LUNs? > But, some devices (at least the Clariion raid > chassis) report luns that don't currently have any device bound to them as > present but offline. This meant if we truly scanned all luns then we got > something like 100+ devices on one ID from this chassis when only 1 might be > valid:-( 16384 LUNs for Fibre Channel. As you see, scanning is out of the question. You must issue REPORT LUNs and fall back on scanning if the device reports a check condition. I did that when I worked in Sun Storage with A5000/A3500/T3 arrays couple of years ago. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE poweroff -> hangup
Ello folkz, Ummm the same problem I am facing whenevr I try to mount my cdrom. I am using kernel 2.4.2 ac-18 and yep ofcourse I am not removing my cdrom power supply.. I tried hdparm -T and got ide_dmaproc: chipset supported ide_dma_timeout func only: 14 I have ASUS 440BX/F mb with intel PIIX4 chipset.. any suggestion Regardz daCodez > > Balazs > > OH the funwhat do you think you are doing? > Since you have not issued a power down command nor deregisterd the device, > because I have not publish hotswap-ata yetthus you can not do this in > a pretty way. grumbles for Bryce. > You are lucky that you have to burned the mainboard. > The open-collector pull on the channel will destroy the buffers on the > device. By pulling the power you can not hold the state of the latches > derived from the power-ground lines. > > There is no kernel bug! > > Does it not occur to you that by dropping the power on the device you > cause it to revert to the default values from POST? > You have successfully unsynced the HOST and the DEVICE as the timings for > the transfer rates. So it should HANG and DIE! > > Just be glad that the kernel will crash and not eat your data. > > Regards, > > Andre Hedrick > Linux ATA Development > > > On Thu, 15 Mar 2001, Pozsar Balazs wrote: > > > > > Hi all, > > > > I was courious, and I tried what happens if I power down my harddisk (ie > > manually pull the power plug out), and then power it on again after a few > > secs (put the plug back). > > > > I do not know if the system should survive happily such an 'accident', but > > it hadn't: > > A few secs after the next access to the disc, I got the following on the > > console: > > hdg: timeout waiting for DMA > > ide_dmaproc: chipset supported ide_dma_timeout func only: 14 > > and the machine froze the hard way (no respond to sysrq). > > > > Tell me if this shouldn't be honoured by the kernel, but if there's a bug > > around, here's some info: > > > > Linux version 2.4.2 ([EMAIL PROTECTED]) (gcc version 2.95.3 19991030 (prerelease)) #1 SMP Wed Mar 7 22:58:36 CET 2001 > > BIOS-provided physical RAM map: > > BIOS-e820: 0009fc00 @ (usable) > > BIOS-e820: 0400 @ 0009fc00 (reserved) > > BIOS-e820: 0001 @ 000f (reserved) > > BIOS-e820: 1000 @ fec0 (reserved) > > BIOS-e820: 1000 @ fee0 (reserved) > > BIOS-e820: 0001 @ (reserved) > > BIOS-e820: 17ef @ 0010 (usable) > > BIOS-e820: d000 @ 17ff3000 (ACPI data) > > BIOS-e820: 3000 @ 17ff (ACPI NVS) > > Scan SMP from c000 for 1024 bytes. > > Scan SMP from c009fc00 for 1024 bytes. > > Scan SMP from c00f for 65536 bytes. > > found SMP MP-table at 000f5770 > > hm, page 000f5000 reserved twice. > > hm, page 000f6000 reserved twice. > > hm, page 000f1000 reserved twice. > > hm, page 000f2000 reserved twice. > > On node 0 totalpages: 98288 > > zone(0): 4096 pages. > > zone(1): 94192 pages. > > zone(2): 0 pages. > > Intel MultiProcessor Specification v1.1 > > Virtual Wire compatibility mode. > > OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0 > > Processor #0 Pentium(tm) Pro APIC version 17 > > Floating point unit present. > > Machine Exception supported. > > 64 bit compare & exchange supported. > > Internal APIC present. > > SEP present. > > MTRR present. > > PGE present. > > MCA present. > > CMOV present. > > Bootup CPU > > Bus #0 is PCI > > Bus #1 is PCI > > Bus #2 is ISA > > I/O APIC #2 Version 17 at 0xFEC0. > > Int: type 3, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 00 > > Int: type 0, pol 0, trig 0, bus 2, IRQ 01, APIC ID 2, APIC INT 01 > > Int: type 0, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 02 > > Int: type 0, pol 0, trig 0, bus 2, IRQ 03, APIC ID 2, APIC INT 03 > > Int: type 0, pol 0, trig 0, bus 2, IRQ 04, APIC ID 2, APIC INT 04 > > Int: type 0, pol 0, trig 0, bus 2, IRQ 06, APIC ID 2, APIC INT 06 > > Int: type 0, pol 0, trig 0, bus 2, IRQ 07, APIC ID 2, APIC INT 07 > > Int: type 0, pol 1, trig 1, bus 2, IRQ 08, APIC ID 2, APIC INT 08 > > Int: type 0, pol 0, trig 0, bus 2, IRQ 0c, APIC ID 2, APIC INT 0c > > Int: type 0, pol 0, trig 0, bus 2, IRQ 0d, APIC ID 2, APIC INT 0d > > Int: type 0, pol 0, trig 0, bus 2, IRQ 0e, APIC ID 2, APIC INT 0e > > Int: type 0, pol 0, trig 0, bus 2, IRQ 0f, APIC ID 2, APIC INT 0f > > Int: type 0, pol 3, trig 3, bus 2, IRQ 09, APIC ID 2, APIC INT 09 > > Int: type 0, pol 3, trig 3, bus 2, IRQ 05, APIC ID 2, APIC INT 05 > > Int: type 0, pol 3, trig 3, bus 2, IRQ 0b, APIC ID 2, APIC INT 0b > > Int: type 0, pol 3, trig 3, bus 2, IRQ 0a, APIC ID 2, APIC INT 0a > > Lint: type 3, pol 0, trig 0, bus 2, IRQ 00, APIC ID ff, APIC LINT 00 > > Lint: type 1, pol 0, trig 0, bus 2, IRQ 00, APIC ID ff, APIC LINT 01 > > Processors: 1 > > mapped APIC to
scsi_scan problem.
A bug report I was charged with fixing (qla2x00 driver doesn't see all luns or
sees multiple identical luns in different scenarios) was not a bug in the
qla2x00 driver. The recent changes to allow max luns in the mid layer to be >
7 seems to have caused this problem. However, the proper fix is a bit of a
quandry for me. You see, I don't have any Nakamichi or Yamaha multi-cd
changers, or a DAT or DLT autoloader, or several of the different models of
raid chassis. The bug is that we were detecting offline devices and linking
them into the device list. But, some devices (at least the Clariion raid
chassis) report luns that don't currently have any device bound to them as
present but offline. This meant if we truly scanned all luns then we got
something like 100+ devices on one ID from this chassis when only 1 might be
valid :-( So, I've attached a patch that solves the problem here perfectly.
But, I need people that have access to the above listed hardware to test it.
Most specifically, I'm afraid that the CD changers or autoloaders will report
some of their luns as offline so we will skip them even though we want them
entered into the device list. If that's not the case, and they list their
luns as all being connected, then this patch needs to go into the mainstream
kernel.
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
--- scsi_scan.c.saveWed Mar 14 20:58:21 2001
+++ scsi_scan.c Wed Mar 14 21:10:28 2001
@@ -557,6 +557,23 @@
}
/*
+* If we are offline and we are on a LUN != 0, then skip this entry.
+* If we are on a BLIST_FORCELUN device this will stop the scan at
+* the first offline LUN (typically the correct thing to do). If
+* we are on a BLIST_SPARSELUN device then this won't stop the scan,
+* but it will keep us from having false entries in our device
+* array. DL
+*
+* NOTE: Need to test this to make sure it doesn't cause problems
+* with tape autoloaders, multidisc CD changers, and external
+* RAID chassis that might use sparse luns or multiluns... DL
+*/
+ if (lun != 0 && (scsi_result[0] >> 5) == 1) {
+ scsi_release_request(SRpnt);
+ return 0;
+ }
+
+ /*
* Get any flags for this device.
*/
bflags = get_device_flags (scsi_result);
@@ -776,11 +793,26 @@
*
* FIXME(eric) - perhaps this should be a kernel configurable?
*/
+ /*
if (*max_dev_lun < shpnt->max_lun)
*max_dev_lun = shpnt->max_lun;
elseif ((max_scsi_luns >> 1) >= *max_dev_lun)
*max_dev_lun += shpnt->max_lun;
else*max_dev_lun = max_scsi_luns;
+ */
+ /*
+* Blech...the above code is broken. When you have a device
+* that is present, and it is a SPARSELUN device, then we
+* need to scan *all* the luns on that device. Besides,
+* skipping the scanning of LUNs is a false optimization.
+* Scanning for a LUN on a present device is a very fast
+* operation, it's scanning for devices that don't exist that
+* is expensive and slow (although if you are truly scanning
+* through MAX_SCSI_LUNS devices that would be bad, I hope
+* all of the controllers out there set a reasonable value
+* in shpnt->max_lun). DL
+*/
+ *max_dev_lun = shpnt->max_lun;
*sparse_lun = 1;
return 1;
}
@@ -795,11 +827,26 @@
* I think we need REPORT LUNS in future to avoid scanning
* of unused LUNs. But, that is another item.
*/
+ /*
if (*max_dev_lun < shpnt->max_lun)
*max_dev_lun = shpnt->max_lun;
elseif ((max_scsi_luns >> 1) >= *max_dev_lun)
*max_dev_lun += shpnt->max_lun;
else*max_dev_lun = max_scsi_luns;
+ */
+ /*
+* Blech...the above code is broken. When you have a device
+* that is present, and it is a FORCELUN device, then we
+* need to scan *all* the luns on that device. Besides,
+* skipping the scanning of LUNs is a false optimization.
+* Scanning for a LUN on a present device is a very fast
+* operation, it's scanning for devices that don't exist that
+* is expensive and slow (although if you are truly scanning
+* through MAX_SCSI_LUNS devices that would be bad, I
determining max process slots at runtime
hi is it possible to determine the maximum number of processes at runtime? I know about #define NR_TASKS, but that might not work if the binary is run on a different machine than the one the program was compiled on. PS I'm not looking for the maximum number of processes per user. I've found that by getrusage(). TIA matthew love software engineer networkharmoni pty ltd. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, Mar 14, 2001 at 05:53:16PM -0800, Tim Wright wrote: > Well, if it sounds useful, I can look into putting up the design documentation > (yes, shock, horror, there is some :-). It's pretty thorough and covers most > of the issues involved, and hence might be a good talking point, even if we > chose to implement quite differently. I'd be interested in seeing it, and I'm sure other developers would too. If you need a place to host it, I can offer a spot on the linux-hotplug sourceforge site for it. thanks, greg k-h -- greg@(kroah|wirex).com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, Mar 14, 2001 at 10:15:26AM -0800, Greg KH wrote: [My ramblings on device naming database deleted] > This comes up a lot with regards to USB devices too. One of the > usb-serial drivers (the edgeport driver) did something like this by > looking at the topology of the USB bus and where a specific device was > (it was also helped by unique serial numbers) and allowed the devices to > be assigned device nodes based on the topology and a small user space > program. I'm going to try to do this for all usb-serial devices in 2.5 > > I can see a scheme like this being very useful for all USB, FireWire, > scsi, etc type of devices. > > And no, I don't think that having some type of device naming "database" > is overkill and will eventually make it into parts of the kernel (the > "database" living outside of the kernel of course...) > Well, if it sounds useful, I can look into putting up the design documentation (yes, shock, horror, there is some :-). It's pretty thorough and covers most of the issues involved, and hence might be a good talking point, even if we chose to implement quite differently. Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel bug in 2.4.2 (TYPO CORRECTED)
Re-sending with correction to typographical error. The version number for the modutils rpm (2.4.2-1) matches the version number for the kernel non-rpm (2.4.2). Sorry if the typo in my previous message might have led to an incorrect diagnosis. Kernel 2.4.2 on a uniprocessor Pentium-MMX. Kernel PCMCIA 3.1.22 is built-in. PCMCIA 3.1.24 package is added. Cardinfo applet was used in ejecting the network card. Network configuration applet was not used so the network driver must have thought that the network interface was still active. Base distribution is Red Hat 7J (default language Japanese). Update rpms were applied for gcc 2.96-69, glibc 2.2-12, modutils 2.4.2-1, and ksymoops 2.4.0-3. The kernel and PCMCIA packages, mentioned at the beginning of this message, were not from rpms. /var/log/messages contains nothing useful: Mar 14 17:34:29 localhost syslog: klogd shutdown succeeded Mar 14 17:34:29 localhost exiting on signal 15 Mar 14 17:55:05 localhost syslogd 1.3-3: restart Following are the last lines displayed on the screen: [several irrelevant successful shutdowns omitted] Shutting down system logger: [ OK ] Shutting down interface eth0: Scheduling in interrupt kernel BUG at sched.c:681! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00010282 eax: 001b ebx: c02fbe00 ecx: 0001 edx: c02c9d88 esi: edi: c3aa3140 ebp: c02fbd6c esp: c02fbd40 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c02fb000) Stack: c026124b c02613b6 02a9 001d c02fa000 c02fa000 c02cad00 c02fbe00 c02fa000 c02fbe00 0001 c0107ac4 0001 c02fa000 c02fbe0c c02fbe0c c02fbdc0 c02cabe0 c0107c10 c02fbe00 0014 0001 c0257319 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c 8d 65 f4 5b 5e 5f 5d c3 55 89 e5 57 56 53 83 Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing ksymoops 2.4.0 on i586 2.4.2. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.2/ (default) -m /boot/System.map-2.4.2 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. kernel BUG at sched.c:681! invalid operand: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010282 eax: 001b ebx: c02fbe00 ecx: 0001 edx: c02c9d88 esi: edi: c3aa3140 ebp: c02fbd6c esp: c02fbd40 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c02fb000) Stack: c026124b c02613b6 02a9 001d c02fa000 c02fa000 c02cad00 c02fbe00 c02fa000 c02fbe00 0001 c0107ac4 0001 c02fa000 c02fbe0c c02fbe0c c02fbdc0 c02cabe0 c0107c10 c02fbe00 0014 0001 c0257319 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [>EIP; c011<= Trace; c0107ac4 <__down+54/a0> Trace; c0107c10 <__down_failed+8/c> Trace; c0257319 Trace; c0120330 <__call_usermodehelper+0/30> Trace; c0120330 <__call_usermodehelper+0/30> Code; c011 <_EIP>: Code; c011<= 0: 0f 0b ud2a <= Code; c0113335 2: 83 c4 0c add$0xc,%esp Code; c0113338 5: 8d 65 f4 lea0xfff4(%ebp),%esp Code; c011333b 8: 5bpop%ebx Code; c011333c 9: 5epop%esi Code; c011333d a: 5fpop%edi Code; c011333e b: 5dpop%ebp Code; c011333f c: c3ret Code; c0113340 <__wake_up+0/b0> d: 55push %ebp Code; c0113341 <__wake_up+1/b0> e: 89 e5 mov%esp,%ebp Code; c0113343 <__wake_up+3/b0> 10: 57push %edi Code; c0113344 <__wake_up+4/b0> 11: 56push %esi Code; c0113345 <__wake_up+5/b0> 12: 53push %ebx Code; c0113346 <__wake_up+6/b0> 13: 83 00 00 addl $0x0,(%eax) Kernel panic: Aiee, killing interrupt handler! 1 warning issued. Results may not be reliable. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux on the Unisys ES7000 and CMP2 machines?
jdow wrote: > Miles, if these babies are the 32 processor monsters that UniSys > has been making recently there IS interest to get Linux on it. > But the people I know who have mentioned "interest", mostly from > a curiosity standpoint, have their hands neatly tied by Microsoft. > Ya see, the developers at UniSys have NT source licenses so they > can develop the HALs for the monsters. Microsoft insists that they > spend a considerable time away from OS development before working > on another OS. So, no Linux port is in the offing, I suspect. The > people who KNOW the machine are not allowed to do it. I just saw one of these 32 processor machines at Internet World, and the engineer said that AIX and the successor to SCO Unix would also run on the machine. Perhaps the engineers doing the AIX port are under less restrictive terms. (When the two people he was talking to asked about Linux on the machine, he said "We feel Linux can't do enterprise-level stuff like this." He got a little defensive when we questioned his judgement.) - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel bug in 2.4.2
Kernel 2.4.2 on a uniprocessor Pentium-MMX. Kernel PCMCIA 3.1.22 is built-in. PCMCIA 3.1.24 package is added. Cardinfo applet was used in ejecting the network card. Network configuration applet was not used so the network driver must have thought that the network interface was still active. Base distribution is Red Hat 7J (default language Japanese). Update rpms were applied for gcc 2.96-69, glibc 2.2-12, modutils 2.4.1-1, and ksymoops 2.4.0-3. The kernel and PCMCIA packages, mentioned at the beginning of this message, were not from rpms. /var/log/messages contains nothing useful: Mar 14 17:34:29 localhost syslog: klogd shutdown succeeded Mar 14 17:34:29 localhost exiting on signal 15 Mar 14 17:55:05 localhost syslogd 1.3-3: restart Following are the last lines displayed on the screen: [several irrelevant successful shutdowns omitted] Shutting down system logger: [ OK ] Shutting down interface eth0: Scheduling in interrupt kernel BUG at sched.c:681! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00010282 eax: 001b ebx: c02fbe00 ecx: 0001 edx: c02c9d88 esi: edi: c3aa3140 ebp: c02fbd6c esp: c02fbd40 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c02fb000) Stack: c026124b c02613b6 02a9 001d c02fa000 c02fa000 c02cad00 c02fbe00 c02fa000 c02fbe00 0001 c0107ac4 0001 c02fa000 c02fbe0c c02fbe0c c02fbdc0 c02cabe0 c0107c10 c02fbe00 0014 0001 c0257319 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c 8d 65 f4 5b 5e 5f 5d c3 55 89 e5 57 56 53 83 Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing ksymoops 2.4.0 on i586 2.4.2. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.2/ (default) -m /boot/System.map-2.4.2 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. kernel BUG at sched.c:681! invalid operand: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010282 eax: 001b ebx: c02fbe00 ecx: 0001 edx: c02c9d88 esi: edi: c3aa3140 ebp: c02fbd6c esp: c02fbd40 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c02fb000) Stack: c026124b c02613b6 02a9 001d c02fa000 c02fa000 c02cad00 c02fbe00 c02fa000 c02fbe00 0001 c0107ac4 0001 c02fa000 c02fbe0c c02fbe0c c02fbdc0 c02cabe0 c0107c10 c02fbe00 0014 0001 c0257319 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [>EIP; c011<= Trace; c0107ac4 <__down+54/a0> Trace; c0107c10 <__down_failed+8/c> Trace; c0257319 Trace; c0120330 <__call_usermodehelper+0/30> Trace; c0120330 <__call_usermodehelper+0/30> Code; c011 <_EIP>: Code; c011<= 0: 0f 0b ud2a <= Code; c0113335 2: 83 c4 0c add$0xc,%esp Code; c0113338 5: 8d 65 f4 lea0xfff4(%ebp),%esp Code; c011333b 8: 5bpop%ebx Code; c011333c 9: 5epop%esi Code; c011333d a: 5fpop%edi Code; c011333e b: 5dpop%ebp Code; c011333f c: c3ret Code; c0113340 <__wake_up+0/b0> d: 55push %ebp Code; c0113341 <__wake_up+1/b0> e: 89 e5 mov%esp,%ebp Code; c0113343 <__wake_up+3/b0> 10: 57push %edi Code; c0113344 <__wake_up+4/b0> 11: 56push %esi Code; c0113345 <__wake_up+5/b0> 12: 53push %ebx Code; c0113346 <__wake_up+6/b0> 13: 83 00 00 addl $0x0,(%eax) Kernel panic: Aiee, killing interrupt handler! 1 warning issued. Results may not be reliable. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH for 2.5] preemptible kernel
Here is the latest preemptible kernel patch. It's much cleaner and smaller than previous versions, so I've appended it to this mail. This patch is against 2.4.2, although it's not intended for 2.4. I'd like comments from anyone interested in a low-latency Linux kernel solution for the 2.5 development tree. Kernel preemption is not allowed while spinlocks are held, which means that this patch alone cannot guarantee low preemption latencies. But as long held locks (in particular the BKL) are replaced by finer-grained locks, this patch will enable lower latencies as the kernel also becomes more scalable on large SMP systems. Notwithstanding the comments in the Configure.help section for CONFIG_PREEMPT, I think this patch has a negligible effect on throughput. In fact, I got better average results from running 'dbench 16' on a 750MHz PIII with 128MB with kernel preemption turned on (~30MB/s) than on the plain 2.4.2 kernel (~26MB/s). (I had to rearrange three headers files that are needed in sched.h before task_struct is defined, but which include inline functions that cannot now be compiled until after task_struct is defined. I chose not to move them into sched.h, like d_path(), as I don't want to make it more difficult to apply kernel patches to my kernel source tree.) Nigel Gamble[EMAIL PROTECTED] Mountain View, CA, USA. http://www.nrg.org/ diff -Nur 2.4.2/CREDITS linux/CREDITS --- 2.4.2/CREDITS Wed Mar 14 12:15:49 2001 +++ linux/CREDITS Wed Mar 14 12:21:42 2001 @@ -907,8 +907,8 @@ N: Nigel Gamble E: [EMAIL PROTECTED] -E: [EMAIL PROTECTED] D: Interrupt-driven printer driver +D: Preemptible kernel S: 120 Alley Way S: Mountain View, California 94040 S: USA diff -Nur 2.4.2/Documentation/Configure.help linux/Documentation/Configure.help --- 2.4.2/Documentation/Configure.help Wed Mar 14 12:16:10 2001 +++ linux/Documentation/Configure.help Wed Mar 14 12:22:04 2001 @@ -130,6 +130,23 @@ If you have system with several CPU's, you do not need to say Y here: APIC will be used automatically. +Preemptible Kernel +CONFIG_PREEMPT + This option reduces the latency of the kernel when reacting to + real-time or interactive events by allowing a low priority process to + be preempted even if it is in kernel mode executing a system call. + This allows applications that need real-time response, such as audio + and other multimedia applications, to run more reliably even when the + system is under load due to other, lower priority, processes. + + This option is currently experimental if used in conjuction with SMP + support. + + Say Y here if you are building a kernel for a desktop system, embedded + system or real-time system. Say N if you are building a kernel for a + system where throughput is more important than interactive response, + such as a server system. Say N if you are unsure. + Kernel math emulation CONFIG_MATH_EMULATION Linux can emulate a math coprocessor (used for floating point diff -Nur 2.4.2/arch/i386/config.in linux/arch/i386/config.in --- 2.4.2/arch/i386/config.in Wed Mar 14 12:14:18 2001 +++ linux/arch/i386/config.in Wed Mar 14 12:20:02 2001 @@ -161,6 +161,11 @@ define_bool CONFIG_X86_IO_APIC y define_bool CONFIG_X86_LOCAL_APIC y fi + bool 'Preemptible Kernel' CONFIG_PREEMPT +else + if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then + bool 'Preemptible SMP Kernel (EXPERIMENTAL)' CONFIG_PREEMPT + fi fi if [ "$CONFIG_SMP" = "y" -a "$CONFIG_X86_CMPXCHG" = "y" ]; then diff -Nur 2.4.2/arch/i386/kernel/entry.S linux/arch/i386/kernel/entry.S --- 2.4.2/arch/i386/kernel/entry.S Wed Mar 14 12:17:37 2001 +++ linux/arch/i386/kernel/entry.S Wed Mar 14 12:23:42 2001 @@ -72,7 +72,7 @@ * these are offsets into the task-struct. */ state = 0 -flags = 4 +preempt_count = 4 sigpending = 8 addr_limit = 12 exec_domain= 16 @@ -80,8 +80,30 @@ tsk_ptrace = 24 processor = 52 +/* These are offsets into the irq_stat structure + * There is one per cpu and it is aligned to 32 + * byte boundry (we put that here as a shift count) + */ +irq_array_shift = CONFIG_X86_L1_CACHE_SHIFT + +irq_stat_softirq_active = 0 +irq_stat_softirq_mask = 4 +irq_stat_local_irq_count= 8 +irq_stat_local_bh_count = 12 + ENOSYS = 38 +#ifdef CONFIG_SMP +#define GET_CPU_INDX movl processor(%ebx),%eax; \ +shll $irq_array_shift,%eax +#define GET_CURRENT_CPU_INDX GET_CURRENT(%ebx); \ + GET_CPU_INDX +#define CPU_INDX (,%eax) +#else +#define GET_CPU_INDX +#define GET_CURRENT_CPU_INDX GET_CURRENT(%ebx) +#define CPU_INDX +#endif #define SAVE_ALL \ cld; \ @@ -270,16 +292,44 @@ #endif jne handle_softirq +#ifdef CONFIG_PREEMPT + cli + incl preempt_count(%ebx) +#endif
[OOPS] in usbcore, 2.4.2-ac17
Got the following oops while starting quake2 (one time) and running mpg123 (another time). It seems pretty reproduceable. Kernel version 2.4.2-ac17, motherboard is a i810 chipset eMachines Caveat emptor, this was typed by hand, but the two oopsen, after being entered, where identical, so unless I made the same typo twice (or miscopied twice)... CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: ebx: 1850 ecx: c1127e8c edx: esi: 0401 edi: 000a ebp: c1127e64 esp: c021bf0c ds: 0018 es: 0018 ss: 0018 Stack: c117cce0 0401 000a c021bfa0 0001 c021bf98 c0168946 8140 0001 c011bcd4 0001 c485b127 c1127e64 c021bf98 c026352c c011b7e6 c020a3c0 c011940f c0109f2d 000a c116a6e4 c021bfa0 0140 Call Trace: [][][][][][][] [][][][][][][] Code: f7 71 14 89 51 20 8b 41 28 40 83 e0 1f 89 41 28 8a 41 28 8d >>EIP; c4858364 <[usbcore]usb_drivers_purge+240/288> <= Trace; c0168946 Trace; c011bcd4 Trace; c485b127 <[usbcore]usb_get_port_status+f/38> Trace; c011b7e6 Trace; c011940f Trace; c0109f2d Trace; c010a08e Trace; c0108db0 Trace; c01a6bcd Trace; c01a697c Trace; c0107120 Trace; c01071a9 Trace; c0105000 Trace; c0100191 Code; c4858364 <[usbcore]usb_drivers_purge+240/288> <_EIP>: Code; c4858364 <[usbcore]usb_drivers_purge+240/288> <= 0: f7 71 14 div0x14(%ecx),%eax <= Code; c4858367 <[usbcore]usb_drivers_purge+243/288> 3: 89 51 20 mov%edx,0x20(%ecx) Code; c485836a <[usbcore]usb_drivers_purge+246/288> 6: 8b 41 28 mov0x28(%ecx),%eax Code; c485836d <[usbcore]usb_drivers_purge+249/288> 9: 40inc%eax Code; c485836e <[usbcore]usb_drivers_purge+24a/288> a: 83 e0 1f and$0x1f,%eax Code; c4858371 <[usbcore]usb_drivers_purge+24d/288> d: 89 41 28 mov%eax,0x28(%ecx) Code; c4858374 <[usbcore]usb_drivers_purge+250/288> 10: 8a 41 28 mov0x28(%ecx),%al Code; c4858377 <[usbcore]usb_drivers_purge+253/288> 13: 8d 00 lea(%eax),%eax -- -Steven Never ask a geek why, just nod your head and slowly back away. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE poweroff -> hangup
Balazs OH the funwhat do you think you are doing? Since you have not issued a power down command nor deregisterd the device, because I have not publish hotswap-ata yetthus you can not do this in a pretty way. grumbles for Bryce. You are lucky that you have to burned the mainboard. The open-collector pull on the channel will destroy the buffers on the device. By pulling the power you can not hold the state of the latches derived from the power-ground lines. There is no kernel bug! Does it not occur to you that by dropping the power on the device you cause it to revert to the default values from POST? You have successfully unsynced the HOST and the DEVICE as the timings for the transfer rates. So it should HANG and DIE! Just be glad that the kernel will crash and not eat your data. Regards, Andre Hedrick Linux ATA Development On Thu, 15 Mar 2001, Pozsar Balazs wrote: > > Hi all, > > I was courious, and I tried what happens if I power down my harddisk (ie > manually pull the power plug out), and then power it on again after a few > secs (put the plug back). > > I do not know if the system should survive happily such an 'accident', but > it hadn't: > A few secs after the next access to the disc, I got the following on the > console: > hdg: timeout waiting for DMA > ide_dmaproc: chipset supported ide_dma_timeout func only: 14 > and the machine froze the hard way (no respond to sysrq). > > Tell me if this shouldn't be honoured by the kernel, but if there's a bug > around, here's some info: > > Linux version 2.4.2 ([EMAIL PROTECTED]) (gcc version 2.95.3 19991030 (prerelease)) >#1 SMP Wed Mar 7 22:58:36 CET 2001 > BIOS-provided physical RAM map: > BIOS-e820: 0009fc00 @ (usable) > BIOS-e820: 0400 @ 0009fc00 (reserved) > BIOS-e820: 0001 @ 000f (reserved) > BIOS-e820: 1000 @ fec0 (reserved) > BIOS-e820: 1000 @ fee0 (reserved) > BIOS-e820: 0001 @ (reserved) > BIOS-e820: 17ef @ 0010 (usable) > BIOS-e820: d000 @ 17ff3000 (ACPI data) > BIOS-e820: 3000 @ 17ff (ACPI NVS) > Scan SMP from c000 for 1024 bytes. > Scan SMP from c009fc00 for 1024 bytes. > Scan SMP from c00f for 65536 bytes. > found SMP MP-table at 000f5770 > hm, page 000f5000 reserved twice. > hm, page 000f6000 reserved twice. > hm, page 000f1000 reserved twice. > hm, page 000f2000 reserved twice. > On node 0 totalpages: 98288 > zone(0): 4096 pages. > zone(1): 94192 pages. > zone(2): 0 pages. > Intel MultiProcessor Specification v1.1 > Virtual Wire compatibility mode. > OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0 > Processor #0 Pentium(tm) Pro APIC version 17 > Floating point unit present. > Machine Exception supported. > 64 bit compare & exchange supported. > Internal APIC present. > SEP present. > MTRR present. > PGE present. > MCA present. > CMOV present. > Bootup CPU > Bus #0 is PCI > Bus #1 is PCI > Bus #2 is ISA > I/O APIC #2 Version 17 at 0xFEC0. > Int: type 3, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 00 > Int: type 0, pol 0, trig 0, bus 2, IRQ 01, APIC ID 2, APIC INT 01 > Int: type 0, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 02 > Int: type 0, pol 0, trig 0, bus 2, IRQ 03, APIC ID 2, APIC INT 03 > Int: type 0, pol 0, trig 0, bus 2, IRQ 04, APIC ID 2, APIC INT 04 > Int: type 0, pol 0, trig 0, bus 2, IRQ 06, APIC ID 2, APIC INT 06 > Int: type 0, pol 0, trig 0, bus 2, IRQ 07, APIC ID 2, APIC INT 07 > Int: type 0, pol 1, trig 1, bus 2, IRQ 08, APIC ID 2, APIC INT 08 > Int: type 0, pol 0, trig 0, bus 2, IRQ 0c, APIC ID 2, APIC INT 0c > Int: type 0, pol 0, trig 0, bus 2, IRQ 0d, APIC ID 2, APIC INT 0d > Int: type 0, pol 0, trig 0, bus 2, IRQ 0e, APIC ID 2, APIC INT 0e > Int: type 0, pol 0, trig 0, bus 2, IRQ 0f, APIC ID 2, APIC INT 0f > Int: type 0, pol 3, trig 3, bus 2, IRQ 09, APIC ID 2, APIC INT 09 > Int: type 0, pol 3, trig 3, bus 2, IRQ 05, APIC ID 2, APIC INT 05 > Int: type 0, pol 3, trig 3, bus 2, IRQ 0b, APIC ID 2, APIC INT 0b > Int: type 0, pol 3, trig 3, bus 2, IRQ 0a, APIC ID 2, APIC INT 0a > Lint: type 3, pol 0, trig 0, bus 2, IRQ 00, APIC ID ff, APIC LINT 00 > Lint: type 1, pol 0, trig 0, bus 2, IRQ 00, APIC ID ff, APIC LINT 01 > Processors: 1 > mapped APIC to e000 (fee0) > mapped IOAPIC to d000 (fec0) > Kernel command line: root=/dev/hdg4 apm=power-off noapic mem=393152K > Initializing CPU#0 > Detected 434.815 MHz processor. > Console: colour VGA+ 80x25 > Calibrating delay loop... 865.07 BogoMIPS > Memory: 384580k/393152k available (856k kernel code, 8184k reserved, 294k data, 184k >init, 0k highmem) > Dentry-cache hash table entries: 65536 (order: 7, 524288 bytes) > Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes) > Page-cache hash table entries: 131072 (order:
Re: [PATCH] Improved version reporting
On Wed, Mar 14, 2001 at 08:29:53PM +0100, [EMAIL PROTECTED] wrote: > There is no other source. Some people like to repack but that > has no influence on versions. I believe that RedHat don't build mount and util-linux from the same tree. Maybe they do internally, but when you look at the RPMs, they appear separate: Name: mount Source RPM: mount-2.10m-6.src.rpm Name: util-linux Source RPM: util-linux-2.10m-12.src.rpm There don't appear to be any explicit dependencies between these two packages either, but they do just happen to have the same version. (I'm looking at the RH7.0 RPMs here). This of course means that the version of mount may not match the version of util-linux installed on the system. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
IDE poweroff -> hangup
Hi all, I was courious, and I tried what happens if I power down my harddisk (ie manually pull the power plug out), and then power it on again after a few secs (put the plug back). I do not know if the system should survive happily such an 'accident', but it hadn't: A few secs after the next access to the disc, I got the following on the console: hdg: timeout waiting for DMA ide_dmaproc: chipset supported ide_dma_timeout func only: 14 and the machine froze the hard way (no respond to sysrq). Tell me if this shouldn't be honoured by the kernel, but if there's a bug around, here's some info: Linux version 2.4.2 ([EMAIL PROTECTED]) (gcc version 2.95.3 19991030 (prerelease)) #1 SMP Wed Mar 7 22:58:36 CET 2001 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 1000 @ fec0 (reserved) BIOS-e820: 1000 @ fee0 (reserved) BIOS-e820: 0001 @ (reserved) BIOS-e820: 17ef @ 0010 (usable) BIOS-e820: d000 @ 17ff3000 (ACPI data) BIOS-e820: 3000 @ 17ff (ACPI NVS) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. found SMP MP-table at 000f5770 hm, page 000f5000 reserved twice. hm, page 000f6000 reserved twice. hm, page 000f1000 reserved twice. hm, page 000f2000 reserved twice. On node 0 totalpages: 98288 zone(0): 4096 pages. zone(1): 94192 pages. zone(2): 0 pages. Intel MultiProcessor Specification v1.1 Virtual Wire compatibility mode. OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0 Processor #0 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. SEP present. MTRR present. PGE present. MCA present. CMOV present. Bootup CPU Bus #0 is PCI Bus #1 is PCI Bus #2 is ISA I/O APIC #2 Version 17 at 0xFEC0. Int: type 3, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 00 Int: type 0, pol 0, trig 0, bus 2, IRQ 01, APIC ID 2, APIC INT 01 Int: type 0, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 02 Int: type 0, pol 0, trig 0, bus 2, IRQ 03, APIC ID 2, APIC INT 03 Int: type 0, pol 0, trig 0, bus 2, IRQ 04, APIC ID 2, APIC INT 04 Int: type 0, pol 0, trig 0, bus 2, IRQ 06, APIC ID 2, APIC INT 06 Int: type 0, pol 0, trig 0, bus 2, IRQ 07, APIC ID 2, APIC INT 07 Int: type 0, pol 1, trig 1, bus 2, IRQ 08, APIC ID 2, APIC INT 08 Int: type 0, pol 0, trig 0, bus 2, IRQ 0c, APIC ID 2, APIC INT 0c Int: type 0, pol 0, trig 0, bus 2, IRQ 0d, APIC ID 2, APIC INT 0d Int: type 0, pol 0, trig 0, bus 2, IRQ 0e, APIC ID 2, APIC INT 0e Int: type 0, pol 0, trig 0, bus 2, IRQ 0f, APIC ID 2, APIC INT 0f Int: type 0, pol 3, trig 3, bus 2, IRQ 09, APIC ID 2, APIC INT 09 Int: type 0, pol 3, trig 3, bus 2, IRQ 05, APIC ID 2, APIC INT 05 Int: type 0, pol 3, trig 3, bus 2, IRQ 0b, APIC ID 2, APIC INT 0b Int: type 0, pol 3, trig 3, bus 2, IRQ 0a, APIC ID 2, APIC INT 0a Lint: type 3, pol 0, trig 0, bus 2, IRQ 00, APIC ID ff, APIC LINT 00 Lint: type 1, pol 0, trig 0, bus 2, IRQ 00, APIC ID ff, APIC LINT 01 Processors: 1 mapped APIC to e000 (fee0) mapped IOAPIC to d000 (fec0) Kernel command line: root=/dev/hdg4 apm=power-off noapic mem=393152K Initializing CPU#0 Detected 434.815 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 865.07 BogoMIPS Memory: 384580k/393152k available (856k kernel code, 8184k reserved, 294k data, 184k init, 0k highmem) Dentry-cache hash table entries: 65536 (order: 7, 524288 bytes) Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes) Page-cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) CPU: Before vendor init, caps: 0183fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 128K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0183fbff CPU: After generic, caps: 0183fbff CPU: Common caps: 0183fbff Enabling fast FPU save and restore... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel CPU: Before vendor init, caps: 0183fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 128K Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0183fbff CPU: After generic, caps: 0183fbff CPU: Common caps: 0183fbff CPU0: Intel Celeron (Mendocino) stepping 05
Adaptec/DPT RAID Drivers [Was: Re: DPT Driver Status]
Marko/Dalton/Unfortunate person searching for working DPT drivers, I too once felt your pain. Searched far and wide, etc. But then I stumbled upon ftp://ftp.suse.com/pub/people/mantel/next/ Which has patches for everything you could ever want, all integrated, if you choose them to be. Anyway, inside those .tgz's was version 2.0 of the DPT I2O drivers. I've separated them from the .tgz, and stuck them up here: Kernel 2.2.18: http://aurore.net/source/dpt_i2o-2.0-2.2.18.gz Kernel 2.4.2 http://aurore.net/source/dpt_i2o-2.0-2.4.2.gz Try 'em! :-) Not sure how they compare to Markos' version. I exchanged my ASR2100S for a Mylex AcceleRAID 170 - because DAC960 support is so much better ;-) and I loved reading through the DAC960 sources - so clean and easy to understand! Regards, Omar Kilani At 03:15 PM 3/14/01 +0200, Marko Kreen wrote: >On Wed, Mar 14, 2001 at 01:32:18AM -0500, Dalton Calford wrote: > > I have searched the archives, hunted through the adaptec site, tried > > multiple patches, compilers, revisions. > >Me too... > > > > > I have a DPT/Adaptec DPT RAID V century card. This has been a topic of > > much discussion in the past on this list. > > > > What I have found is that almost every file I find has a patch that is 6 > > months old at best. > >When I last contacted them, couple of months ago, through >I-dunno-how-many-middle[wo]men they assured that >"driver is in developement" and "soon we make a release"... > > > I even contacted Deanna Bonds at Adaptec, but she has been unresponsive. > > > > Does anyone have a working patch for the 2.2.18 kernel? > > What is the most stable version of the kernel for the use of the patch? > >I have ported the 1.14 version of the driver to 2.2.18. >Basically converted their idea of patching with cp to >normal diff and dropped all reverse changes. > > http://www.l-t.ee/marko/linux/dpt114-2.2.18p22.diff.gz > >It was for pre22 but applies cleanly to final 2.2.18. >The other soft was most current in valinux site: > > http://ftp.valinux.com/pub/mirrors/dpt/ > > > Has the native i2o driver been updated to handle what the dpt card is > > doing? > >No, the DPT driver has not been updated to native Linux i2o. > >Note: the driver compiles only with gcc 2.7.2.3, (dunno about >egcs). 2.95.2 makes it acting weird. I do not know if >thats gcc or driver problem. > >-- >marko > >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to [EMAIL PROTECTED] >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IBM ServerRAID 4L firmware 4.40.03
-- Forwarded by Robert Miciovici/Romania/ADSW/A-D on 03/15/2001 12:42 AM --- Robert Miciovici 03/14/2001 11:11 PM To: "ServeRAID For Linux" <[EMAIL PROTECTED]> cc: Subject: Re: IBM ServerRAID 4L firmware 4.40.03 (Document link: Robert Miciovici) Hi, Look what I can provide as further info about my failure to install RH7 on the Netfinity 5100 with the ServerRAID 4L controller: I boot in "expert text" mode from the original bootable CD created after the iso image available on ftp.redhat.com/ and of course I have the IBM ServerRAID for driver for Linux diskette in the floppy drive look what I get on one of the installation log screens: * Cannot find /tmp/drivers/rhdd-6.1; bad driver disk * Cannot find /tmp/drivers/modinfo; bad driver disk * Cannot find /tmp/drivers/modules.dep; bad driver disk * Cannot find /tmp/drivers/pcitable; bad driver disk and * trying to mount device /tmp/fd0 * going to insmod ips.o (path is NULL) /tmp/ips.o: init_module: %m Hint: this error can be caused by incorrect module parameters, including invalid IO or IRQ parameters I also tried mounting the driver floppy and insert the module manually but I couldn't even mount the floppy in the shell provided by the RH 7.0 install... Oddly I can install RedHat 6.2 with the same driver diskette on the same machine anytime. What do you say, how should I approach this one? Please help me. Best regards, Robert "ServeRAID For Linux" <[EMAIL PROTECTED]> on 02/26/2001 08:00:11 PM To: "Robert Miciovici" <[EMAIL PROTECTED]> cc: Subject: IBM ServerRAID 4L firmware 4.40.03 Red Hat 7 contains version 4.20 if the ips driver. It should install on a ServeRAID 4L ( even without a driver diskette ). If you want to use the 4.50 driver diskette during install, it also works. I have installed RH 7 many times using the current ( 4.50 ) diskette and have never seen a problem. BTW, Keith left IBM in December. "Robert Miciovici" <[EMAIL PROTECTED]> on 02/26/2001 12:15:00 PM To: Keith Mitchell <[EMAIL PROTECTED]> cc: Subject: IBM ServerRAID 4L firmware 4.40.03 Hi Keith, I know that you are busy, and I apologise for taking up a little of your precios time, but I would like to ask you a simple question. How could I install RedHat 7.0 on a Netfinity 5100 with a IBM ServerRAID 4L firmware 4.40.03 ? I already tried with the latest driver diskette but it's not working, says something like: ips module couldn't be loaded complaining about probably some incorrect module parameters (which I didn't supply manually and I don't know what should I). Btw: RedHat 6.2 installs like a charm with the same drivers diskette. Thank you, Best regards, Robert DISCLAIMER: This e-mail contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail. This message has been scanned for the presence of computer viruses. This message has been scanned for the presence of computer viruses. -- DISCLAIMER: This e-mail contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail. Please note that users should have no expectation that any information they transmit or receive over Allied Domecq facilities or stored on Allied Domecq computers is or will remain private, and Allied Domecq reserves the right to review these records. Allied Domecq reserves the right to intercept, monitor and record this e-mail. This message has been scanned for the presence of computer viruses. --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: another Cyrix/mtrr problem?
[EMAIL PROTECTED] (Bob_Tracy) writes: > Unfortunately, when I execute > > echo "base=0xd800 size=0x10 type=write-combining" >| /proc/mtrr > > I get a 2MB region instead of the 1MB region I expected... Oops, it got broken by the MTRR >32-bit support in 2.4.0-testX. The patch below should fix it. Joerg, I think this might well fix your Cyrix mtrr problem also. Let me know how it goes, Dave Wragg diff -uar linux-2.4.2/arch/i386/kernel/mtrr.c linux-2.4.2.cyrix/arch/i386/kernel/mtrr.c --- linux-2.4.2/arch/i386/kernel/mtrr.c Thu Feb 22 15:24:53 2001 +++ linux-2.4.2.cyrix/arch/i386/kernel/mtrr.c Wed Mar 14 22:28:02 2001 @@ -538,7 +538,7 @@ * Note: shift==0xf means 4G, this is unsupported. */ if (shift) - *size = (reg < 7 ? 0x1UL : 0x40UL) << shift; + *size = (reg < 7 ? 0x1UL : 0x40UL) << (shift - 1); else *size = 0; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alert on LAN for Linux?
In article <[EMAIL PROTECTED]> you wrote: > Alert on LAN makes the system up from power management type sleep when > there are packets to be processed. Why you would ever have sleep mode on > a server is beyond me. Most professional UPS with Network Management Cards can go a sever to sleep mode if the power gets down and they will awake the Server with a "Wake-on-Lan" signal if power is back. Afaik Wake-On-Lan is a Mainboard/Bios Feature and will work with any OS which can put the System into the right Sleep mode. Greetings Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: State of RAID (and the infamous FastTrak100 card)
On Wed, Mar 14, 2001 at 03:58:01PM -0500, Phil Edwards wrote:
> [I am not subscribed at the moment (don't ask :), so please cc me.]
>
> A few months ago there was a brief discussion about the FastTrak100 card
> and the driver that Promise provides, and just what all can (technically)
> be done. It eventually became a debate about what may (legally) be done
> with the driver, and then turned into another "what the GPL /really/
> says" thread. :-)
>
> I've just read all those messages from the archives. And I've been
> skimming the RAID-related HOWTOs at linuxdoc.org, but many seem out of date.
> One in particular starts off by saying that the stock 2.2 support is buggy,
> and that the "new" version is much improved, but requires patches and a
> rebuild, and is still alpha code. Of course, the doc saying it's alpha
> is itself a year old.
Ok, I get the feeling it may be the Software-RAID howto you're referring to
here... Let me explain why it's not updated.
Fact is, I haven't updated the document because 99% of what it says is still
the perfect truth.
Software-RAID in 2.2 is buggy and requires patching to go to the so-called
alpha versions (which the HOWTO explains are not alpha-quality but actually
quite usable).
However, 2.4 is out and doesn't need patching, and I should probably update the
howto to reflect that. But still, most of what's in the HOWTO is as correct as
it can be.
>
> The MAINTAINERS and Documentation/* files don't mention the FastTrack100
> (not surprising, it's not OSS) nor software RAID (also unsurprising,
> it's software).
FastTrack100 RAID *is* software RAID - The software is in the proprietary
drivers for the card.
But it's confusing, and Andre Hedrick has already explained this mess on
several occations here on LKML. Search the archives.
>
> So... am I just begging for pain if I try to install, say, a stock RH7
> on a machine with the FastTrak100 doing it's little RAID0/JBOD thing?
> If it requires this machine to always boot from a floppy because the driver
> cannot be linked into the kernel, well, I'm okay with that.
I don't know about the state of the FastTrak100 IDE drivers - but if you can
get that running, putting software RAID on top of that should be a simple
matter.
>
> RH7 ships with 2.2.16. Is building a new 2.2.18 kernel just going to
> shoot me in the head with this card (and Promise's proprietary driver)?
RH 2.2 kernels have "real" software RAID - stock 2.2 needs patching.
>
> What's the state of RAID in the 2.4 kernels?
Good. No patches needed - software RAID in 2.4 rocks. And 2.4 supports more
IDE controllers - but again I don't know the state of FastTrak100.
>
> I'm very leery of solutions that involve lots of patches to the 2.2.x kernel,
> because I have to have a working system in order to rebuild a kernel... and
> I would have to patch the kernel before I can install/boot the system... and
> there will be no other hard drives available in the machine; just the two
> being striped (or glued) by the FastTrak100 Card of Doom.
Use plain RedHat kernels, or patch your own :)
You can boot on software RAID - it's in the HOWTO ;)
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] found small type in Documentation/sysctl/vm.txt (fwd)
Hi Alan, Linus, could you please apply Marty's patch for the next pre-kernel ? thanks, Rik -- Forwarded message -- Date: Wed, 14 Mar 2001 15:17:05 -0500 From: Marty Leisner <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: found small type in Documentation/sysctl/vm.txt I was looking through the documentation to understand the /proc stuff... Looked in the wrong place... Mistake is also in 2.4.2.. :1 leisner@thingy; rcsdiff -u vm.txt === RCS file: vm.txt,v retrieving revision 1.1 diff -u -r1.1 vm.txt --- vm.txt 2001/03/14 20:11:27 1.1 +++ vm.txt 2001/03/14 20:11:43 @@ -32,7 +32,7 @@ This file controls the operation of the bdflush kernel daemon. The source code to this struct can be found in -linux/mm/buffer.c. It currently contains 9 integer values, +linux/fs/buffer.c. It currently contains 9 integer values, of which 6 are actually used by the kernel. From linux/fs/buffer.c: marty [EMAIL PROTECTED] Don't confuse education with schooling. Milton Friedman to Yogi Berra - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: Rename all derived CONFIG variables
On Mon, 12 Mar 2001, Keith Owens wrote: > On Mon, 12 Mar 2001 03:53:07 -0500, > "Eric S. Raymond" <[EMAIL PROTECTED]> wrote: > >But if we're going to push Linus and the kernel crew to switch to > >CML2, then why invite the political tsuris of trying to get a large > >patch into 2.4 now? Maybe I'm missing something here, but this doesn't > >seem necessary to me. > > The derived config variables should be in a separate name space, > whether config is CML1 or CML2. This patch does it for CML1. I don't think this makes sense at all. The derivation of the config values is the concern of the configuration system, not the code. Consider something like CONFIG_CPU_HAS_FEATURE_FOO that might currently be derived from CONFIG_CPU_BAR but may in the future be made independent. Or vice-versa. Your proposed name-change means additional maintenance headache and gets you nothing that you couldn't get by simply including whatever script you wrote to deduce the dependencies. Such a script would at least be able to tell you what a variable was derived from. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] open_namei() braindamage Re: NODEV filesystem, multiplemounts and umount...
On Wed, 14 Mar 2001, Petr Vandrovec wrote: > Hey, it is reproducible: > > mount -t vfat /dev/hda1 /dos/c > mount --bind / /xxx > echo "a" > /xxx/dos/c > > and it stops here... ^C does not work. umount /dos/c fixes it > (creat() returns EISDIR) Very interesting. OK, so path_walk() gives us (vfsmnt of /xxx, dentry of /dos). Then we do down() on ->i_sem of inode of /dos. OK. We find dentry of /dos/c (mountpoint) It's positive, so we drop ->i_sem of parent. Dentry is a mountpoint. We call __follow_down(). Since nothing is mounted under xxx we get unchanged... What the fuck? OK, I'm an idiot. Linus, please apply the following: --- fs/namei.c.oldWed Mar 14 16:37:45 2001 +++ fs/namei.cWed Mar 14 16:38:23 2001 @@ -1013,7 +1013,7 @@ error = -ELOOP; if (flag & O_NOFOLLOW) goto exit_dput; - do __follow_down(>mnt,); while(d_mountpoint(dentry)); + while (__follow_down(>mnt,) && d_mountpoint(dentry)); } error = -ENOENT; if (!dentry->d_inode) Cheers, Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Remote Management (was Re: Alert on LAN)
IBM says, as quoted by Terje Malmedal: > With the latest release, Alert on LAN 2 now extends IT > capabilities to remotely manage and control their > networked PCs: > > Remote system reboot upon report of a critical failure > Repair Operating System > Update BIOS image > Perform other diagnostic procedures OK, fine... but: Where are the authentication and authorization?! Surely I'm not the only person to see in this "Alert On LAN 2" the potential for a security disaster. I know I will never buy anything that supports AOL2 until its security features are openly documented and testable. > The feature I really need is to be able to reset the machine > remotely when Linux is hung. Some current PC motherboards support remote management via a serial line. Of course, you'll need software: The VA Cluster Manager (GPL'd - http://sourceforge.net/projects/vacm) can monitor and control any number of clients, limited only by the number of serial ports you can give it. VACM also includes optional client support for enhanced monitoring, e.g. of temperatures. I'm not sure which motherboards it supports, but I'm sure you can find current documentation. :-) Granted, this is not cheap. A VACM-style approach costs some money for the monitor computer, and some convenience for installing the serial lines; meanwhile, AOL2 promises to do it all over Ethernet. But with VACM, you can be sure that somebody has to log in to the monitor computer -- with security levels you control! -- before they can control or even monitor any connected clients. BTW, in the spirit of full disclosure: VACM is a product of VA Linux engineering, and I work for VA. But VACM is GPL'd and we don't charge for it, so I have little financial interest in seeing it used. I just *hate* it when people play fast & loose with my security. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: (struct dentry *)->vfsmnt;
David Kleikamp writes: > Let me start with a disclaimer stating that it's been a few years since > I've worked with AIX, but this is what I believe happens. > > mount itself doesn't do anything except read /etc/filesytems (AIX's > version of /etc/fstab). LVM maintains the information primarily in the > ODM (yuck). The utilities such as mkfs, mklv, chfs, etc. modify this > information in the ODM. The exportvg command extracts the information > from the ODM (and /etc/filesystems?) and stores it somewhere in the > volume group. Only then can the volume group be imported by another > system with the importvg command, which then populates the ODM and > /etc/filesystems. Actually, I'm pretty sure you _never_ need to exportvg in order to have it work on another system. That's one of the great things about AIX LVM, because it means you can move a VG to another system after a hardware problem, and not have any problems importing it (journaled fs also helps). AFAIK, the only think exportvg does is remove VG information from the ODM and /etc/filesystems. I suppose it is possible that because AIX is so tied into the ODM and SMIT, that it updates the VGDA mountpoint info whenever a filesystem mountpoint is changed, but this will _never_ work on Linux because of different tools versions, distributions, etc. Also, it would mean on AIX that anyone editing /etc/filesystems might have a broken system at vgimport time (wouldn't be the first time that not using ODM/SMIT caused such a problem). > ... I do think that the LVM is a reasonable place to store this kind of > information. Yes, even though it would tie the user into using a specific version of mount(), I suppose it is a better solution than storing it inside the filesystem. It will work with non-ext2 filesystems, and it also allows you to store more information than simply the mountpoint (e.g. mount options, dump + fsck info, etc). In the end, I will probably just save the whole /etc/fstab line into the LV header somewhere, and extract it at importvg time (possibly with modifications for vgname and mountpoint). Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problem with abyss driver in 2.4.2 and newer kernels
The abyss driver will not load on 2.4.2 or 2.4.3-pre4, or 2.4.2-ac20, however it works fine in 2.4.1 Mar 14 13:48:40 jdorse01 kernel: tms380tr.c: v1.08 14/01/2001 by Christoph Goos, Adam Fritzler Mar 14 13:48:40 jdorse01 kernel: abyss.c: v1.02 23/11/2000 by Adam Fritzler Mar 14 13:48:40 jdorse01 kernel: PCI: Found IRQ 7 for device 01:09.0 Mar 14 13:48:40 jdorse01 kernel: tr0: Madge Smart 16/4 PCI Mk2 (Abyss) Mar 14 13:48:40 jdorse01 kernel: tr0:IO: 0xec00 IRQ: 7 Mar 14 13:48:40 jdorse01 kernel: tr0: Memory not accessible for DMA Mar 14 13:48:40 jdorse01 kernel: tr0: unable to get memory for dev->priv. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [RFC] fbdev & power management
On 14 Mar 2001 14:39:57 +0100, Geert Uytterhoeven wrote: > On Wed, 14 Mar 2001, Benjamin Herrenschmidt wrote: > > >I think registering fbcon as a PM client and doing the above when the > > >fbdev suspend/resume hooks are called should work. A memory backup is > > >worked on until the resume is run and the backup is restored to the > > >display. > > > > > >So the fbdev drivers would register PM with fbcon, not PCI, correct? > > > > Either that, or the fbdev would register with PCI (or whatever), _and_ > > fbcon would too independently. In that scenario, fbcon would only handle > > things like disabling the cursor timer, while fbdev's would handle HW > > issues. THe only problem is for fbcon to know that a given fbdev is > > asleep, this could be an exported per-fbdev flag, an error code, or > > whatever. In this case, fbcon can either buffer text input, or fallback > > to the cfb working on the backed up fb image (that last thing can be > > handled entirely within the fbdev I guess). > > I'd go for a fallback to dummycon. It's of no use to waste power on creating > graphical images of the text console when asleep. And the fallback to dummycon > is needed anyway while a fbdev is opened (in 2.5.x). But wouldn't falling back to dummycon prevent the driver specific suspend/resume calls from working? Or at a minimum, make handling those calls more complex? No, there does not need to be graphical images of the text console -- a simply text buffer would suffice. But what about things like GTKFb and Embedded QT? They would certainly benefit from having a backup screen image, right? I do not believe there is any way to determine if the console is in fact in a 'text' or graphical state. Brad Douglas [EMAIL PROTECTED] http://www.linux-fbdev.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
State of RAID (and the infamous FastTrak100 card)
[I am not subscribed at the moment (don't ask :), so please cc me.] A few months ago there was a brief discussion about the FastTrak100 card and the driver that Promise provides, and just what all can (technically) be done. It eventually became a debate about what may (legally) be done with the driver, and then turned into another "what the GPL /really/ says" thread. :-) I've just read all those messages from the archives. And I've been skimming the RAID-related HOWTOs at linuxdoc.org, but many seem out of date. One in particular starts off by saying that the stock 2.2 support is buggy, and that the "new" version is much improved, but requires patches and a rebuild, and is still alpha code. Of course, the doc saying it's alpha is itself a year old. The MAINTAINERS and Documentation/* files don't mention the FastTrack100 (not surprising, it's not OSS) nor software RAID (also unsurprising, it's software). So... am I just begging for pain if I try to install, say, a stock RH7 on a machine with the FastTrak100 doing it's little RAID0/JBOD thing? If it requires this machine to always boot from a floppy because the driver cannot be linked into the kernel, well, I'm okay with that. RH7 ships with 2.2.16. Is building a new 2.2.18 kernel just going to shoot me in the head with this card (and Promise's proprietary driver)? What's the state of RAID in the 2.4 kernels? I'm very leery of solutions that involve lots of patches to the 2.2.x kernel, because I have to have a working system in order to rebuild a kernel... and I would have to patch the kernel before I can install/boot the system... and there will be no other hard drives available in the machine; just the two being striped (or glued) by the FastTrak100 Card of Doom. Much thanks, Phil -- pedwards at disaster dot jaj dot com | pme at sources dot redhat dot com devphil at several other less interesting addresses in various dot domains The gods do not protect fools. Fools are protected by more capable fools. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OOPS] 8139too
> Hello LKML! > i686 2.4.2 UP+kdb+lm_sensors+pcmcia > after APM laptop suspend to disk > 8139too is build-in, not pcmcia > I often get hangups after suspend-to-disk if I'm connected to a hub/switch. > This is the first oops I've actually seen and copied it by hand: I remember a similar bug report. Was the nic connected or not? It seems that rtl8139_resume() unconditionally enables the nic, even if it wasn't open()'ed. Then an interrupt arrives and crashes because some memory structures were not allocated. -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: (struct dentry *)->vfsmnt;
On Wed, Mar 14, 2001 at 02:32:21PM -0500, Alexander Viro wrote: > Sorry - .last.mounted in the root of filesystem, indeed. > > > The writing side can't be done in userland without basically making > > mount(8) know about the superblock layout of each and every filesystem: > > That's a wonderful reason to put it _not_ into superblock... OK, what's > wrong with the variant above? The information will not be available without mounting the filesystem first. However - the LVM way sounded much better, so this may not matter. -- Ragnar Kjørstad Big Storage - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with SCSI on 2.4.X
[EMAIL PROTECTED] wrote: > I'm having some problems using SCSI-generic (sg loaded as module) to > access my scanner on linux 2.4 (using SANE). > > [snip output showing timeouts] This is most likely caused by a bug in SANE 1.0.3 and 1.0.4 which sets timeouts on commands to 10 seconds rather than 10 minutes. The SANE code detects the new sg driver in lk 2.4.x and mistakenly shortens the timeout. This has been fixed in SANE's CVS (and RedHat's 7.1 beta (fisher)). Fix for SANE 1.0.4 : in file sane-backends-1.0.4/sanei/sanei_scsi.c change line 1893 from: req->sgdata.sg3.hdr.timeout = 1; to req->sgdata.sg3.hdr.timeout = 10 * 60 * 1000; If you look at the FAQ on the sg web site ( http://www.torque.net/sg ) under the SANE entry you will find the same information ... Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: system call for process information?
On Wed, 14 Mar 2001, Szabolcs Szakacsits wrote: > > On Wed, 14 Mar 2001, Alexander Viro wrote: > > On Wed, 14 Mar 2001, Szabolcs Szakacsits wrote: > > > read() doesn't really work for this purpose, it blocks way too many > > > times to be very annoying. When finally data arrives it's useless. > > Huh? Take code of your non-blocking syscall. Make it ->read() for > > relevant file on /proc or wherever else you want it. See read() not > > blocking... > > Sorry I should have quoted "blocks". Problem isn't with blocking but > *no* data, no information. In the end you can conclude you know > *nothing* what happend in the last t time interval - this can be second, > minutes even with an RT, mlocked, etc process when the load is around 0. And how will a new syscall avoid the same problems you have with read()? Again, they can share the payload code - it's a matter of calling conventions and layout of the output. _That_ part doesn't take long. If reading is too slow - too bad, changing the syscall number won't help. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, 14 Mar 2001, Christoph Hellwig wrote: > In article <[EMAIL PROTECTED]> you >wrote: > > > The problem: > > > drivers change their detection schemes; and changes in the kernel can > > change the order in which devices are assigned names. > > > > For example, the DAC960(?) drivers changed their order of > > detecting controllers, and I did _not_ have fun, given that the machine in > > question had about 40 disks to deal with, spread across two controllers. > > Put LABEL= in you fstab in place of the device name. It solves the example, but not necessarily the problem. We're still left with partitions that don't do labels, attached tape devices, scsi controllers, NICs, and so forth. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: system call for process information?
On Wed, 14 Mar 2001, Alexander Viro wrote: > On Wed, 14 Mar 2001, Szabolcs Szakacsits wrote: > > read() doesn't really work for this purpose, it blocks way too many > > times to be very annoying. When finally data arrives it's useless. > Huh? Take code of your non-blocking syscall. Make it ->read() for > relevant file on /proc or wherever else you want it. See read() not > blocking... Sorry I should have quoted "blocks". Problem isn't with blocking but *no* data, no information. In the end you can conclude you know *nothing* what happend in the last t time interval - this can be second, minutes even with an RT, mlocked, etc process when the load is around 0. Szaka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, Mar 14, 2001 at 02:11:57PM -0500, Lars Kellogg-Stedman wrote: > > Put LABEL= in you fstab in place of the device name. > > Which is great, for filesystems that support labels. Unfortunately, > this isn't universally available -- for instance, you cannot mount > a swap partition by label or uuid, so it is not possible to completely > isolate yourself from the problems of disk device renumbering. True. Let's mark for 2.5 ToDO list: magic number for swap... Just because it does not work universally it doesn't have to be a bad idea... Christoph -- Of course it doesn't work. We've performed a software upgrade. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: system call for process information?
On Wed, 14 Mar 2001, Szabolcs Szakacsits wrote: > > On Mon, 12 Mar 2001, Alexander Viro wrote: > > On Mon, 12 Mar 2001, Guennadi Liakhovetski wrote: > > > I need to collect some info on processes. One way is to read /proc > > > tree. But isn't there a system call (ioctl) for this? And what are those > > Occam's Razor. Why invent new syscall when read() works? > > read() doesn't really work for this purpose, it blocks way too many > times to be very annoying. When finally data arrives it's useless. Huh? Take code of your non-blocking syscall. Make it ->read() for relevant file on /proc or wherever else you want it. See read() not blocking... Whether code blocks or not depends on the code, not on the calling conventions. And definitely not on ASCII vs. binary - conversion between these formats _is_ doable without blocking operations. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: static scheduling - SCHED_IDLE?
On Wed, 14 Mar 2001, Jamie Lokier wrote: > > 2. load control, when the VM starts thrashing we can just > >suspend a few processes to make sure the system as a > >whole won't thrash to death > > Surely it would be easier, and more appropriate, to make the > processes sleep when they next page fault. This should work ... Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: poll() behaves differently in Linux 2.4.1 vs. Linux 2.2.14 (POLLHUP)
Hello! > True, this behavior was changed from 2.2.x. We now match the behavior > of other svr4 systems, in particular Solaris. Damn, we did not test behaviour on absolutely new clean never connected socket... Solaris really may return 0 on it. However, looking from other hand the issue looks as absolutely academic and not related to practice in any way. Alexey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: (struct dentry *)->vfsmnt;
Let me start with a disclaimer stating that it's been a few years since I've worked with AIX, but this is what I believe happens. mount itself doesn't do anything except read /etc/filesytems (AIX's version of /etc/fstab). LVM maintains the information primarily in the ODM (yuck). The utilities such as mkfs, mklv, chfs, etc. modify this information in the ODM. The exportvg command extracts the information from the ODM (and /etc/filesystems?) and stores it somewhere in the volume group. Only then can the volume group be imported by another system with the importvg command, which then populates the ODM and /etc/filesystems. Of course, I would NEVER suggest anything resembling AIX's ODM, but I do think that the LVM is a reasonable place to store this kind of information. Andreas Dilger wrote: > > David Kleikamp writes: > > AIX stores all of this information in the LVM, not in the filesystem. > > The filesystem itself has nothing to do with importing and exporting > > volume groups. Having the information stored as part of LVM's metadata > > allows the utilities to only deal with LVM instead of every individual > > file system. > > So you are saying that mount(8) writes into a field in the LVM LVCB or > something? Might be possible on Linux LVM as well... > > Cheers, Andreas > -- > Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, > \ would they cancel out, leaving him still hungry?" > http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert -- David J. Kleikamp IBM Linux Technology Center - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: (struct dentry *)->vfsmnt;
On Wed, 14 Mar 2001, Andreas Dilger wrote: > David Kleikamp writes: > > AIX stores all of this information in the LVM, not in the filesystem. > > The filesystem itself has nothing to do with importing and exporting > > volume groups. Having the information stored as part of LVM's metadata > > allows the utilities to only deal with LVM instead of every individual > > file system. > > So you are saying that mount(8) writes into a field in the LVM LVCB or > something? Might be possible on Linux LVM as well... Makes sense. Even better than per-fs file in root on filesystems affected by that policy. If the situation when you really want it is LVM putting that (and probably fs type and other mount options) into LVM metadata looks like a good idea. Cheers, Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, 14 Mar 2001, Lars Kellogg-Stedman wrote: > > Put LABEL= in you fstab in place of the device name. > > Which is great, for filesystems that support labels. Unfortunately, > this isn't universally available -- for instance, you cannot mount > a swap partition by label or uuid, so it is not possible to completely > isolate yourself from the problems of disk device renumbering. > > -- Lars > > -- > Lars Kellogg-Stedman <[EMAIL PROTECTED]> > When my BIOS finds IDE disks, it starts at the lowest address of the port. It then looks for the first master, then the slave(s), etc. Then it tries the second, etc. When my SCSI BIOS finds disks, it starts at the first controller, the first LUN, the first drive, etc. This used to even be the way disks were located by the kernel drivers. Now, these are found in some "random" order. If whatever is causing the "random" order was fixed, put back like it used to be, etc., we wouldn't have these problems. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: system call for process information?
On Mon, 12 Mar 2001, Alexander Viro wrote: > On Mon, 12 Mar 2001, Guennadi Liakhovetski wrote: > > I need to collect some info on processes. One way is to read /proc > > tree. But isn't there a system call (ioctl) for this? And what are those > Occam's Razor. Why invent new syscall when read() works? read() doesn't really work for this purpose, it blocks way too many times to be very annoying. When finally data arrives it's useless. Szaka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel paging oops on massive vfs activity
Hey kernel developers,
I'm getting repeated oopses and occasional freezes on a server I've
set up to host a giant (180G) reiserfs system atop lvm, served by nfs(v2).
(I've applied the reiserfs and nfs patches to the vanilla kernel,
which is otherwise pretty minimally compiled). They seem to be
correlated by massive disk activity. Because this file system has
many huge directories (2+ files in some) and also many long names
(some of those giant directories are filled with 40+ character
filenames) I'm beginning to wonder whether the vfs layer is at fault.
I got some of the same behavior with an earlier ext2 instance atop
lvm. In this case I triggered the result by doing a find atop the
tree. Generally things that access many directory entries trigger it.
Of course, it could be a remaining hardware glitch on this new tbird
1100 system on GA59X motherboard (latest firmware, but it has the
troublesome VIA kt133 chipset).
What use is a server when it oopses when trying to serve?
Any thoughts?
Don Barry
Cornell Astronomy
ksymoops 2.3.4 on i686 2.4.2. Options used
-V (specified)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.2/ (default)
-m /usr/src/linux/System.map (default)
Unable to handle kernel paging request at virtual address 00acaca0
c0141adb
*pde =
Oops:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010217
eax: cffc9f58 ebx: 00acac80 ecx: 000e edx: 0001be9b
esi: 00acac80 edi: ebp: cffc9f58 esp: c96c9e1c
ds: 0018 es: 0018 ss: 0018
Process find (pid: 929, stackpage=c96c9000)
Stack: c96c9e94 0001be9b cf921400 c0141ef7 cf921400 0001be9b cffc9f58
c96c9e74 c96c9e94 c96c9ef8 c96c9ed4 c2545bc0 cffc9f58 c0180e04
cf921400 0001be9b c96c9e74 c96c9e94 0001 0001bdb0 c017c7de
Call Trace: [] [] [] [] []
[] []
[] []
Code: 39 53 20 75 24 8b 54 24 14 39 93 8c 00 00 00 75 18 85 ff 74
>>EIP; c0141adb<=
Trace; c0141ef7
Trace; c0180e04
Trace; c017c7de
Trace; c01385a3
Trace; c0138d27
Trace; c013830b
Trace; c013935c <__user_walk+3c/60>
Trace; c0136206
Trace; c0108f47
Code; c0141adb
<_EIP>:
Code; c0141adb<=
0: 39 53 20 cmp%edx,0x20(%ebx) <=
Code; c0141ade
3: 75 24 jne29 <_EIP+0x29> c0141b04
Code; c0141ae0
5: 8b 54 24 14 mov0x14(%esp,1),%edx
Code; c0141ae4
9: 39 93 8c 00 00 00 cmp%edx,0x8c(%ebx)
Code; c0141aea
f: 75 18 jne29 <_EIP+0x29> c0141b04
Code; c0141aec
11: 85 ff test %edi,%edi
Code; c0141aee
13: 74 00 je 15 <_EIP+0x15> c0141af0
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: (struct dentry *)->vfsmnt;
David Kleikamp writes: > AIX stores all of this information in the LVM, not in the filesystem. > The filesystem itself has nothing to do with importing and exporting > volume groups. Having the information stored as part of LVM's metadata > allows the utilities to only deal with LVM instead of every individual > file system. So you are saying that mount(8) writes into a field in the LVM LVCB or something? Might be possible on Linux LVM as well... Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
From: Riley Williams <[EMAIL PROTECTED]> [Yes, I wrote, replying to your mail, just because I happened to notice the incorrect or debatable lines in your patch. Let me cc the Changes maintainer - maybe Chris Ricker.] >> -o util-linux 2.10o # fdformat --version >> +o util-linux # 2.10o# fdformat --version > Looking at fdformat to get the util-linux version is perhaps not > the most reliable way - some people have fdformat from elsewhere. > Using mount --version would be better - I am not aware of any > other mount distribution. RedHat distribute mount separately from util-linux and I wouldnae be surprised if others do the same... I am not aware of any distribution that ships some version of util-linux, but replaces its mount part by an older version. I think that even in cases where, because of historical reasons, util-linux is repackaged in several parts, mount --version gives the right answer. >> +In addition, it is wise to ensure that the following packages are >> +at least at the versions suggested below, although these may not >> +be required, depending on the exact configuration of your system: >> + >> +o Console Tools # 0.3.3# loadkeys -V >> +o Mount # 2.10e# mount --version > Concerning mount: > > (i) the version mentioned is too old, > (ii) mount is in util-linux. Not on RedHat systems. There is no other source. Some people like to repack but that has no influence on versions. > Conclusion: the mount line should be deleted entirely. > Concerning Console Tools: maybe kbd-1.05 is uniformly better. > I am not aware of any reason to recommend the use of console-tools. Neither am I. The ver_linux script has lines for determining the versions for both Console Tools and Kbd but on EVERY system I've tried, including Slackware, RedHat, Debian, Caldera, and SuSE based ones, the line for determining Kbd versiondoesnae work. I've just included the line that worked, and ignored the Kbd one as I can see no point including something that doesnae work. You are mistaken, as is proved by the reports that contain a kbd line: a grep on linux-kernel for this Februari shows people with Kbd 0.96, 0.99 and 1.02. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: magic device renumbering was -- Re: Linux 2.4.2ac20
Lars writes: > > Put LABEL= in you fstab in place of the device name. > > Which is great, for filesystems that support labels. Unfortunately, > this isn't universally available -- for instance, you cannot mount > a swap partition by label or uuid, so it is not possible to completely > isolate yourself from the problems of disk device renumbering. There is room for a LABEL and/or UUID in the swap superblock, if you would want to implement support for this. I took a look once, and it should be possible to add in a compatible way. Of course, you can always put swap into LVM, which also makes it (along with filesystems other than ext2) immune from the nasty device name changes. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: (struct dentry *)->vfsmnt;
On Wed, 14 Mar 2001, Andreas Dilger wrote: > Obviously, the whole vgimport stuff is going to be in userland. The only > part that needs to go in the kernel is storing the mountpoint in the > filesystem superblock. It is _not_ OK to just put it in /.last.mounted. > Quite often a data/application VG is moved independent of the root filesystem. > The info needs to stay with the filesystem itself. Sorry - .last.mounted in the root of filesystem, indeed. > > Since the reading side contains a bunch of heuristics > > (obviously depending on the local naming policy for temp. mountpoints, > > for one thing) you don't need anything special on the writing side... > > The writing side can't be done in userland without basically making > mount(8) know about the superblock layout of each and every filesystem: That's a wonderful reason to put it _not_ into superblock... OK, what's wrong with the variant above? Cheers, Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: (struct dentry *)->vfsmnt;
AIX stores all of this information in the LVM, not in the filesystem. The filesystem itself has nothing to do with importing and exporting volume groups. Having the information stored as part of LVM's metadata allows the utilities to only deal with LVM instead of every individual file system. Andreas Dilger wrote: > > Al writes: > > On Tue, 13 Mar 2001, Andreas Dilger wrote: > > > > > On AIX, it is possible to import a volume group, and it automatically > > > builds /etc/fstab entries from information stored in the fs. Having the > > > "last mounted on" would have the mount point info, and of course LVM > > > would hold the device names. > > > > Wait a minute. What happens if you bring /home from one box to another, > > that already has /home? Corrupted /etc/fstab? > For the same reason that the UUID and LABEL are stored in the superblock: > you want this infomation kept with the filesystem and not anywhere else, > otherwise it will quickly get out-of-date. Wherever you mounted the > filesystem last is where it would be mounted if you import the VG on > another system. You can obviously edit /etc/fstab afterwards if it is > wrong, and then remount the filesystem(s), and this will store the > correct mountpoint into the filesystem for the next vgimport. -- David J. Kleikamp IBM Linux Technology Center - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: magic device renumbering was -- Re: Linux 2.4.2ac20
Christoph writes: > In article <[EMAIL PROTECTED]> you >wrote: > > drivers change their detection schemes; and changes in the kernel can > > change the order in which devices are assigned names. > > > > For example, the DAC960(?) drivers changed their order of > > detecting controllers, and I did _not_ have fun, given that the machine in > > question had about 40 disks to deal with, spread across two controllers. > > Put LABEL= in you fstab in place of the device name. > P.S. UUID= work, too - but I prefer a human-readable label... Works OK for ext2 only. I'm still waiting on the reiserfs folks to add a UUID and LABEL to their superblock. However, for raw partitions, you will need to use LVM to get rename-safe device labels. You probably want LVM anyways, if you have 40 disks... Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: (struct dentry *)->vfsmnt;
Al writes: > On Wed, 14 Mar 2001, Andreas Dilger wrote: > > The AIX vgimport will not corrupt /etc/fstab with duplicate mounts, nor for > > that matter with duplicate LV names (AIX has a single namespace for all LVs). > > If a conflict is found with an LV name, a new name like "lv01" is used (the > > LV names are not that important anyways). I'm not sure what would > > happen with a duplicate mount point (whether it would pick a new name, or > > simply leave it out of /etc/fstab), but it isn't too hard to think of > > easy ways to fix this (e.g. /home01 or /mnt/vgname/home or whatever). > > Excuse me, but doesn't it scream "userland"? IOW, is there any reason to > do that in the kernel? If you want to spread /etc/fstab all over the > place storing bits in relevant filesystems - fine, you even don't > need to bother with superblocks. Just teach mount(8) to put the > mountpoint into /.last.mounted and be done with that... Obviously, the whole vgimport stuff is going to be in userland. The only part that needs to go in the kernel is storing the mountpoint in the filesystem superblock. It is _not_ OK to just put it in /.last.mounted. Quite often a data/application VG is moved independent of the root filesystem. The info needs to stay with the filesystem itself. > It's a policy question - if somebody wants to play with such > schemes he can do it in the place where policy stuff belongs. > I.e. in userland. Yes, the policy for resolving conflicts and such will be in userland. Yes, the policy for determining the initial mountpoints is done in userland. The only thing I want to do in kernel space is store the mountpoint in the "last mounted" field in the superblock. It also will help InterMezzo to know this information. > Since the reading side contains a bunch of heuristics > (obviously depending on the local naming policy for temp. mountpoints, > for one thing) you don't need anything special on the writing side... The writing side can't be done in userland without basically making mount(8) know about the superblock layout of each and every filesystem: - you create a new filesystem - you mount it When can we update the superblock? At filesystem creation time-> not guaranteed to stay up-to-date. With mount(8) -> needs superblock format of each filesystem. Inside fs-specific kernel code -> about 2 lines of code, if we could just call d_path() or have mountpoint as param. The information is already inside the kernel. I would _actually_ rather just get dir_name from do_mount() down inside *_read_super. However, AFAICT this it is easier (i.e. doesn't change the VFS interface) to pass the d_dir dentry in the generic superblock to *_read_super. If calling d_path() is the wrong thing to do, then I would be happy to hear another way of getting dir_name to *_read_super() without breaking the VFS interface. Cheers, Andreas PS - in 2.2 I can do this with < 10 lines of code (including ext2-specific code). I'm just asking for some _help_ to understand what needs to be done for 2.4. -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: magic device renumbering was -- Re: Linux 2.4.2ac20
> Put LABEL= in you fstab in place of the device name. Which is great, for filesystems that support labels. Unfortunately, this isn't universally available -- for instance, you cannot mount a swap partition by label or uuid, so it is not possible to completely isolate yourself from the problems of disk device renumbering. -- Lars -- Lars Kellogg-Stedman <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpqarray & 2.4.1+ hang
Marcus Meissner wrote: > > Workaround: run the kernel with the 'noapic' option on its commandline. > > The ServerWorks chipset used in this Compaq Server somehow does not pass > the the relevant information to Linux mapping routines. :/ > > I have attached lspci -xxx and dmesg output of our DL360 below. > > Ciao, Marcus Yes that workaround means no hang on bootup anymore, thanks a lot. --- Vincent Sweeney [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, 14 Mar 2001, Christoph Hellwig wrote: > Put LABEL= in you fstab in place of the device name. > > Christoph > > P.S. UUID= work, too - but I prefer a human-readable label... There are a lot of different devices besides disks, e.g. tape drives etc. I seem to remember from the last round this came up that modern FC fabrics have some dynamic properties that may require more intelligence in the kernel. Peter -- Peter Svensson ! Pgp key available by finger, fingerprint: <[EMAIL PROTECTED]>! 8A E9 20 98 C1 FF 43 E3 07 FD B9 0A 80 72 70 AF <[EMAIL PROTECTED]> ! Remember, Luke, your source will be with you... always... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: magic device renumbering was -- Re: Linux 2.4.2ac20
In article <[EMAIL PROTECTED]> you wrote: > The problem: > drivers change their detection schemes; and changes in the kernel can > change the order in which devices are assigned names. > > For example, the DAC960(?) drivers changed their order of > detecting controllers, and I did _not_ have fun, given that the machine in > question had about 40 disks to deal with, spread across two controllers. Put LABEL= in you fstab in place of the device name. Christoph P.S. UUID= work, too - but I prefer a human-readable label... -- Of course it doesn't work. We've performed a software upgrade. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, Mar 14, 2001 at 08:27:10AM -0800, Tim Wright wrote: > This would currently be massive overkill for Linux, but DYNIX/ptx avoids this > problem entirely by keeping a device naming database. This became necessary > when we added support for multi-path fibre-channel connected disks. Most > device-naming conventions rely on "physical" addresses i.e. this disk at the end > of this bus connected to this controller in this PCI slot is /dev/sdd. The > Solaris scheme mentioned above is no different in that respect. Unfortunately, > it doesn't work with multi-path FC-connected devices. > > Very briefly, devices that are "id-able" i.e. already have a unique id are > simply entered into the database (SCSI drives have a unique id that you can > read at autoconf time). For elements that are not "id-able", we establish > a derived id by recording their relation to "id-able" elements. At boot time, > we scan (in parallel) the system and compare what we find to the database. > That way, you get consistent naming for devices, and, at least in the case of > the SCSI (or FC) drives, the name doesn't change, even if you pull a drive > from one bus and plug it into a different bus entirely. This comes up a lot with regards to USB devices too. One of the usb-serial drivers (the edgeport driver) did something like this by looking at the topology of the USB bus and where a specific device was (it was also helped by unique serial numbers) and allowed the devices to be assigned device nodes based on the topology and a small user space program. I'm going to try to do this for all usb-serial devices in 2.5 I can see a scheme like this being very useful for all USB, FireWire, scsi, etc type of devices. And no, I don't think that having some type of device naming "database" is overkill and will eventually make it into parts of the kernel (the "database" living outside of the kernel of course...) greg k-h -- greg@(kroah|wirex).com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] [2.4.3-pre2] Crash (Perhaps reiserfs?)
On Tuesday, March 13, 2001 08:24:55 PM +0100 "Manfred H. Winter" <[EMAIL PROTECTED]> wrote: > Hi! > > A few minutes ago, my system crashed on Linux 2.4.3-pre2. I attach the > log of the crash and what ksymoops says about it. Hmm, oops looks bogus, and the trace in the log file has some symbols missing. I think you should turn off the symbol translation in klogd, and give the pure oops to ksymoops. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: (struct dentry *)->vfsmnt;
On Wed, 14 Mar 2001, Andreas Dilger wrote: > The AIX vgimport will not corrupt /etc/fstab with duplicate mounts, nor for > that matter with duplicate LV names (AIX has a single namespace for all LVs). > If a conflict is found with an LV name, a new name like "lv01" is used (the > LV names are not that important anyways). I'm not sure what would > happen with a duplicate mount point (whether it would pick a new name, or > simply leave it out of /etc/fstab), but it isn't too hard to think of > easy ways to fix this (e.g. /home01 or /mnt/vgname/home or whatever). [snip the rest of description] Excuse me, but doesn't it scream "userland"? IOW, is there any reason to do that in the kernel? If you want to spread /etc/fstab all over the place storing bits in relevant filesystems - fine, you even don't need to bother with superblocks. Just teach mount(8) to put the mountpoint into /.last.mounted and be done with that... It's a policy question - if somebody wants to play with such schemes he can do it in the place where policy stuff belongs. I.e. in userland. Since the reading side contains a bunch of heuristics (obviously depending on the local naming policy for temp. mountpoints, for one thing) you don't need anything special on the writing side... Cheers, Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.x: Netfinity 4500 SMP freezes without any trace
> -Ursprüngliche Nachricht- > Von: Tim Wright [mailto:[EMAIL PROTECTED]] > Gesendet: Mittwoch, 14. März 2001 00:04 > An: Hartmut Holz > Cc: [EMAIL PROTECTED] > Betreff: Re: 2.4.x: Netfinity 4500 SMP freezes without any trace > > > Reboot with 'nmi_watchdog=0'. That will "fix" it for now. > Still chasing this. I'll announce when I find out root cause. > It works. Thank you. Regards Hartmut - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: (struct dentry *)->vfsmnt;
You write: > > For the same reason that the UUID and LABEL are stored in the superblock: > > you want this infomation kept with the filesystem and not anywhere else, > > otherwise it will quickly get out-of-date. Wherever you mounted the > > filesystem last is where it would be mounted if you import the VG on > > another system. You can obviously edit /etc/fstab afterwards if it is > > wrong, and then remount the filesystem(s), and this will store the > > correct mountpoint into the filesystem for the next vgimport. > > Al is saying `why not do this in mount(8) instead of mount(2)?' I haven't > seen you answer that yet. Because this is totally filesystem specific - why put extra knowledge of filesystem internals into mount? I personally don't want it writing into the ext2 or ext3 superblock. How can it possibly know what to do, without embedding a lot of knowledge there? Yes, mount(8) can _read_ the UUID and LABEL for ext2 filesystems, but I would rather not have it _write_ into the superblock. Also, InterMezzo and SnapFS have the same on-disk format as ext2, but would mount(8) know that? There are other filesystems (at least IBM JFS) that could also take advantage of this feature, should we make mount(8) have code for each and every filesystem? Yuck. Sort of ruins the whole modularity thing. Yes, I know mount(8) does funny stuff for SMB and NFS, but that is a reason to _not_ put more filesystem-specific information into mount(8). Actually, one more reason to have this in the kernel is for InterMezzo (distributed filesystem which uses ext3 for on-disk storage). Currently, the mount point is passed as a mount parameter (yuck) because it is needed internally to the InterMezzo kernel code. If the filesystem could extract this information at mount time, it would remove the need for the mount parameter. The benefit of doing all of this in *_read_super() (probably would be in ext2_setup_super() for ext2) is that filesystems which can use this feature will do so, and others will not. It is a matter of a single "d_path()" call at mount (or remount for R/O mounted filesystems), so it is not like it's going to slow down the system a lot. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: your mail
On Sun, Mar 11, 2001 at 09:03:09PM -0800, Greg KH wrote: > On Sun, Mar 11, 2001 at 06:06:24PM +0100, Martin Bruchanov wrote: > > > > Bug report from Martin Bruchanov ([EMAIL PROTECTED], [EMAIL PROTECTED]) > > > > > > [1.] One line summary of the problem: > > USB doesn't work properly with SMP kernel on dual-mainboard or with APIC. > > What kind of motherboard is this? > >From the lspci output, looks like I have the same mainboard or at least one with an identical chipset. I've got an MSI 694D Pro Mainboard with 694X VIA chipset, with 2 cpus installed, and I had the same USB problem with 2.4.0, but haven't had time to test it on a recent kernel. robert > And does USB work in SMP mode with "noapic" given on the kernel command > line? > > thanks, > > greg k-h > > -- > greg@(kroah|wirex).com > http://immunix.org/~greg > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Bug in 2.2 update_vm_cache_conditional?
Hi Alan,
there appears to a bug in update_vm_cache_conditional
that manifests itself only on S/390:
update_vm_cache_conditional is called with a source_address
parameter that can either be a kernel or a user space virtual
address, depending on how get_fs() is set.
update_vm_cache_conditional wants to check whether the
source_address is in fact equal to the destination address
in the page cache. This check should hit only when the
source_address is actually a *kernel* space address; if the
source is a user space address the page cache must always
be updated.
However, update_vm_cache_conditional never checks whether the
address is a kernel address, it does just a
if ((unsigned long)dest != source_address)
On Intel, this is not a problem, as every user space address
is different from every kernel space address anyway.
On S/390, however, the kernel lives in a separate address space,
so shares the same range of addresses as the user spaces. This
means that in certain rare cases, this check can accidentally
hit even if the source lives in user space.
This leads to the page cache update being skipped, and the
page cache is inconsistent with the buffer cache afterwards :-(
Do you agree that this is a bug? What do you think of this fix:
Index: filemap.c
===
RCS file: /home/cvs/linux/mm/filemap.c,v
retrieving revision 1.3
diff -u -r1.3 filemap.c
--- filemap.c 2000/06/09 19:15:25 1.3
+++ filemap.c 2001/03/14 16:52:29
@@ -252,7 +252,8 @@
if (page) {
char *dest = (char*) (offset + page_address(page));
- if ((unsigned long)dest != source_address) {
+ if ( (unsigned long)dest != source_address
+|| !segment_eq(get_fs(), KERNEL_DS)) {
wait_on_page(page);
memcpy(dest, buf, len);
flush_dcache_page(page_address(page));
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand
Linux for S/390 Design & Development
IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
Phone: +49-7031/16-3727 --- Email: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
cpqarray & 2.4.1+ hang
I have a problem with the 2.4 series kernel running on a number of Compaq ProLiant DL360 servers. The 2.2.x kernels and 2.4.0 work fine, however from 2.4.1 onwards the boxes just hang at the following position on bootup: Partition check: ida/c0d0: I have also tested with 2.4.2-ac20 and the same problem occurs. Doing a search on the web some people recommend changing the OS setting in the Compaq BIOS to Linux fixes this problem, however my servers are already running with this BIOS setting and I've also tested with numerous other OS's in the BIOS but the same problem occurs. Has anyone else fixed this problem with changing the BIOS OS? I've also attached my .config file for extra details. --- Vincent Sweeney [EMAIL PROTECTED] config
2.4.2-ac20: Trying to vfree() nonexistent vm area (c8138000)
Hi all, The following appeared on my home box running 2.4.2-ac20. I have X, netscape, and broadcast2000 running on it when this happened. The system is still up, though I have the slightest idea what to check next... any ideas? Mar 15 00:58:25 mmj kernel: Trying to vfree() nonexistent vm area (c8138000) Mar 15 00:58:41 mmj kernel: Trying to vfree() nonexistent vm area (c8138000) -- .--. Michael J. Maravillo office://+63.2.894.3592/ ( () ) Q Linux Solutions, Inc. mobile://+63.917.897.0919/ `--\\ A Philippine Open Source Solutions Co. http://www.q-linux.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: (struct dentry *)->vfsmnt;
On Wed, Mar 14, 2001 at 10:26:50AM -0700, Andreas Dilger wrote: > > Let me put it that way: I don't understand why (if it is useful at all) > > it is done in the fs. Looks like a wrong level... > > For the same reason that the UUID and LABEL are stored in the superblock: > you want this infomation kept with the filesystem and not anywhere else, > otherwise it will quickly get out-of-date. Wherever you mounted the > filesystem last is where it would be mounted if you import the VG on > another system. You can obviously edit /etc/fstab afterwards if it is > wrong, and then remount the filesystem(s), and this will store the > correct mountpoint into the filesystem for the next vgimport. Al is saying `why not do this in mount(8) instead of mount(2)?' I haven't seen you answer that yet. -- Revolutions do not require corporate support. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
Hi Andries.
>> -o util-linux 2.10o # fdformat --version
>> +o util-linux # 2.10o# fdformat --version
> Looking at fdformat to get the util-linux version is perhaps not
> the most reliable way - some people have fdformat from fd-utils
> or so.
{Shrug} That's the command that was in both Documentation/Changes and
in scripts/ver_linux and I just left what was already there, as shown
by your quote. Somebody MUCH more knowledgable than me regarding
kernel requirements can sort that out.
> Using mount --version would be better - I am not aware of any
> other mount distribution.
RedHat distribute mount separately from util-linux and I wouldnae be
surprised if others do the same...
>> +In addition, it is wise to ensure that the following packages are at least
>> +at the versions suggested below, although these may not be required,
>> +depending on the exact configuration of your system:
>> +
>> +o Console Tools # 0.3.3# loadkeys -V
>> +o Mount # 2.10e# mount --version
> Concerning mount:
>
> (i) the version mentioned is too old,
Probably. As stated, that's what's currently installed here, and I
havenae the foggiest whether any of them need upgrading as there's
nothing I've been able to find to say what the minimum version is.
> (ii) mount is in util-linux.
Not on RedHat systems.
> Conclusion: the mount line should be deleted entirely.
Maybe, but that's not for me to decide. Whoever wrote ver_linux
obviously thought it important.
> Concerning Console Tools: maybe kbd-1.05 is uniformly better.
> I am not aware of any reason to recommend the use of console-tools.
Neither am I. The ver_linux script has lines for determining the
versions for both Console Tools and Kbd but on EVERY system I've
tried, including Slackware, RedHat, Debian, Caldera, and SuSE based
ones, the line for determining Kbd versiondoesnae work. I've just
included the line that worked, and ignored the Kbd one as I can see no
point including something that doesnae work.
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: ACPI:system description tables not found.
Stephen, Your BIOS isn't reporting any ACPI capability. If it were you would have at least two more entries in the e820 output that say ACPI NVS and ACPI Reclaim. Have you been able to install a MS OS and have it recognize ACPI? Are there any other BIOS settings that might be related (what about a PnP OS setting or something under Power Management)? You might also check for any BIOS updates available from the motherboard manufacturer. Dave -Original Message- From: Stephen Torri [mailto:[EMAIL PROTECTED]] Sent: Friday, March 09, 2001 1:09 PM To: David Christensen Cc: Linux Kernel Subject: RE: ACPI:system description tables not found. On Thu, 8 Mar 2001, David Christensen wrote: > Stephen, > > Is there a BIOS setup option for enabling ACPI? Make sure it is enabled. The BIOS setup option for ACPI is enabled. > Also attach a copy of the E820 output from dmesg. Linux version 2.4.2 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #2 SMP Mon Feb 26 23:47:16 GMT 2001 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0002 @ 000e (reserved) BIOS-e820: 17f0 @ 0010 (usable) BIOS-e820: 1000 @ fec0 (reserved) BIOS-e820: 1000 @ fee0 (reserved) BIOS-e820: 0004 @ fffc (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. found SMP MP-table at 000fb4f0 hm, page 000fb000 reserved twice. hm, page 000fc000 reserved twice. hm, page 000f2000 reserved twice. hm, page 000f3000 reserved twice. On node 0 totalpages: 98304 zone(0): 4096 pages. zone(1): 94208 pages. zone(2): 0 pages. Stephen --- Buyer's Guide for a Operating System: Don't care to know: Mac Don't mind knowing but not too much: Windows Hit me! I can take it!: Linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: (struct dentry *)->vfsmnt;
Al writes: > On Tue, 13 Mar 2001, Andreas Dilger wrote: > > > On AIX, it is possible to import a volume group, and it automatically > > builds /etc/fstab entries from information stored in the fs. Having the > > "last mounted on" would have the mount point info, and of course LVM > > would hold the device names. > > Wait a minute. What happens if you bring /home from one box to another, > that already has /home? Corrupted /etc/fstab? The AIX vgimport will not corrupt /etc/fstab with duplicate mounts, nor for that matter with duplicate LV names (AIX has a single namespace for all LVs). If a conflict is found with an LV name, a new name like "lv01" is used (the LV names are not that important anyways). I'm not sure what would happen with a duplicate mount point (whether it would pick a new name, or simply leave it out of /etc/fstab), but it isn't too hard to think of easy ways to fix this (e.g. /home01 or /mnt/vgname/home or whatever). It was really useful (i.e. easy to manage) to be able to move a bunch of disks (making a whole volume group) from one system to another, import it, and then not have to mount each filesystem to figure out what the contents are before editing /etc/fstab to set up the correct mount point. In 99.9% of the cases, the mountpoints were correct. I don't think you can ever have a system that is 100% correct all of the time. For AIX, the base filesystems in the rootvg (/, /usr, /var, /tmp, /home, /boot, and swap) all moved as a single unit (sometimes /home was moved out for systems that served lots of users). For data or application specific filesystems, the normal practise was to put them into their own volume group for backup, failover, etc. This made it easy to upgrade systems, or move a critical application to another server in case of hardware problems (whether manual or via HA auto failover). > Let me put it that way: I don't understand why (if it is useful at all) > it is done in the fs. Looks like a wrong level... For the same reason that the UUID and LABEL are stored in the superblock: you want this infomation kept with the filesystem and not anywhere else, otherwise it will quickly get out-of-date. Wherever you mounted the filesystem last is where it would be mounted if you import the VG on another system. You can obviously edit /etc/fstab afterwards if it is wrong, and then remount the filesystem(s), and this will store the correct mountpoint into the filesystem for the next vgimport. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
[EMAIL PROTECTED] writes: >Looking at fdformat to get the util-linux version is perhaps >not the most reliable way - some people have fdformat from fd-utils or so. >Using mount --version would be better - I am not aware of any >other mount distribution. Bad idea. RedHat has mount and util-linux in different RPMs (at least 6.x). Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problems with SCSI on 2.4.X
Hi, I'm having some problems using SCSI-generic (sg loaded as module) to access my scanner on linux 2.4 (using SANE). I've been using 2.2.0 - 2.2.19pre17 without any problems, but when I changed to 2.4 the problems started. 2.4.1 gave the following entries in my kernel log file (id 7 = scsi card, id 6 = scanner, id 0 = hd): Mar 10 20:06:15 palpatine kernel: scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 6, lun 0 Read (6) 00 00 5e 8d 00 Mar 10 20:06:17 palpatine kernel: SCSI host 0 abort (pid 0) timed out - resetting Mar 10 20:06:17 palpatine kernel: SCSI bus is being reset for host 0 channel 0. Mar 10 20:06:28 palpatine kernel: (scsi0:0:0:0) Synchronous at 80.0 Mbyte/sec, offset 15 I saw that the Adaptec driver was changed in the latest prereleases so i tried 2.4.3pre4 which gave me: Mar 14 15:48:10 palpatine kernel: scsi0:0:6:0: Attempting to queue an ABORT message Mar 14 15:48:10 palpatine kernel: (scsi0:A:6:0): Queuing a recovery SCB Mar 14 15:48:10 palpatine kernel: scsi0:0:6:0: Device is disconnected, re-queuing SCB Mar 14 15:48:10 palpatine kernel: Recovery code sleeping Mar 14 15:48:10 palpatine kernel: Recovery SCB completes Mar 14 15:48:10 palpatine kernel: Recovery code awake Mar 14 15:48:10 palpatine kernel: aic7xxx_abort returns 8194 Mar 14 15:48:11 palpatine kernel: scsi0:0:6:0: Attempting to queue a TARGET RESET message Mar 14 15:48:11 palpatine kernel: scsi0:0:6:0: Command not found Mar 14 15:48:11 palpatine kernel: aic7xxx_dev_reset returns 819 If you need more info just mail me and I'll provide it... Thanks, David [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
> Many systems have mount (and bsdutils) separated from util-linux > as a binary package. Built from the same source, indeed, but... I hope that this habit is dying. Long ago that was reasonable, but these days (years) it only causes extra work. >> Concerning Console Tools: maybe kbd-1.05 is uniformly better. >> I am not aware of any reason to recommend the use of console-tools. > Debian has console-tools with priority:required and kbd with priority:extra. > Take it with Yann Dirson... I am not aware of any reason to recommend the use of console-tools. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, Mar 14, 2001 at 10:36:40AM -0500, John Jasen wrote: > > The problem: > [ Device name slippage ] > > Possible solutions(?): > > Solaris uses an /etc/path_to_inst file, to keep track of device ordering, > et al. > > Maybe we should consider something similar, where a physical device to > logical device map is kept and used to keep things consistent on > kernel/driver changes; device addition/removal, and so forth ... > > I am, of course, open to better solutions. > This would currently be massive overkill for Linux, but DYNIX/ptx avoids this problem entirely by keeping a device naming database. This became necessary when we added support for multi-path fibre-channel connected disks. Most device-naming conventions rely on "physical" addresses i.e. this disk at the end of this bus connected to this controller in this PCI slot is /dev/sdd. The Solaris scheme mentioned above is no different in that respect. Unfortunately, it doesn't work with multi-path FC-connected devices. Very briefly, devices that are "id-able" i.e. already have a unique id are simply entered into the database (SCSI drives have a unique id that you can read at autoconf time). For elements that are not "id-able", we establish a derived id by recording their relation to "id-able" elements. At boot time, we scan (in parallel) the system and compare what we find to the database. That way, you get consistent naming for devices, and, at least in the case of the SCSI (or FC) drives, the name doesn't change, even if you pull a drive from one bus and plug it into a different bus entirely. As I say, this would be massive overkill for Linux, but it's a rather thorough solution :-) Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
On Wed, 14 Mar 2001 [EMAIL PROTECTED] wrote: > > +o Console Tools # 0.3.3# loadkeys -V > > +o Mount # 2.10e# mount --version > > Concerning mount: (i) the version mentioned is too old, > (ii) mount is in util-linux. Conclusion: the mount line > should be deleted entirely. Many systems have mount (and bsdutils) separated from util-linux as a binary package. Built from the same source, indeed, but... > Concerning Console Tools: maybe kbd-1.05 is uniformly better. > I am not aware of any reason to recommend the use of console-tools. Debian has console-tools with priority:required and kbd with priority:extra. Take it with Yann Dirson... Cheers, Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: poll() behaves differently in Linux 2.4.1 vs. Linux 2.2.14 (POLLHUP)
What version of Solaris should the poll() call behave like? I tried the test program that I posted in the original post on this thread on a couple of versions of Solaris, and they all behaved like Linux 2.2, not Linux 2.4. The following version strings are from sysinfo on the Solaris machines that I tested: Machine 1: CPU Type is sparcv8plus+vis App Architecture is sparc Kernel Architecture issun4u OS Name isSunOS OS Version is 5.7 OS Distribution isSolaris 7 5/99 s998s_u2SunServer_09 SPARC Kernel Version is SunOS Release 5.7 Version Generic_106541-11 [UNIX(R) System V Release 4.0] Machine 2: SunOS xxx.xxx.xxx.xxx 5.5.1 Generic_103640-29 sun4u sparc SUNW,Ultra-5_10. Does Linux 2.4 poll() behave like Solaris 8 poll() with respect to poll()? If I had access to a Solaris 8 machine I would have tested it because I realize the Solaris versions are a bit out of date. -jeff --- "David S. Miller" <[EMAIL PROTECTED]> wrote: > > Jeffrey Butler writes: > > I've noticed that poll() calls on IPv4 sockets > do > > not behave the same under linux 2.4 vs. linux > 2.2.14. > > Linux 2.4 will return POLLHUP for a socket that > is not > > connected (and has never been connected) while > Linux > > 2.2 will not. > > The following example program demonstrates the > > problem when it's run under linux 2.4: > > True, this behavior was changed from 2.2.x. We now > match the behavior > of other svr4 systems, in particular Solaris. This > new behavior in > 2.4.x will not change. > > Later, > David S. Miller > [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: system call for process information?
Rik van Riel wrote: > > On Wed, 14 Mar 2001, george anzinger wrote: > > > Is it REALLY necessary to prevent them from seeing an > > inconsistent state? Seems to me that in the total picture (i.e. > > system wide) they will never see a consistent state, so why be > > concerned with a small corner of the system. > > You're right. All we need to make sure of is that the address > space we want to print info about doesn't go away while we're > reading the stats ... > > (I think ... but we'll need to look at the procfs code in more > detail) > For what its worth: On the last system I worked on we had a status program that maintained a screen with interesting things such as context switches per sec, disc i/o/sec, lan traffic/sec, ready queue length, next task (printed as current task) and... well a whole 26X80 screen full of stuff. The program gathered all the data by reading system tables as quickly as possible and THEN did the formatting/ screen update. Having to deal with pre formatted data would have a.) widened the capture window and b.) been a real drag to reformat and move to the right screen location. We allowed programs that had the savvy to have read only access to the kernel area to make this as fast as possible. George - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
On Wed, Mar 14, 2001 at 10:39:53AM +, Riley Williams wrote: > -o util-linux 2.10o # fdformat --version > +o util-linux # 2.10o# fdformat --version Looking at fdformat to get the util-linux version is perhaps not the most reliable way - some people have fdformat from fd-utils or so. Using mount --version would be better - I am not aware of any other mount distribution. > +In addition, it is wise to ensure that the following packages are at least > +at the versions suggested below, although these may not be required, > +depending on the exact configuration of your system: > + > +o Console Tools # 0.3.3# loadkeys -V > +o Mount # 2.10e# mount --version Concerning mount: (i) the version mentioned is too old, (ii) mount is in util-linux. Conclusion: the mount line should be deleted entirely. Concerning Console Tools: maybe kbd-1.05 is uniformly better. I am not aware of any reason to recommend the use of console-tools. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 5Mb missing...
Martin Dalecki wrote: > > Jonathan Morton wrote: > > > > The kernel itself takes up some RAM, which is simply subtracted from the > > "total memory available" field in the memory summaries available to > > user-mode processes. This is perfectly normal. > > The kernel reserves 4m for hilself. The off by one error is a rounding > bug. Sounds pretty reasonable. I have actually tested the memory card with memtest, just to make sure that it was all there and working properly, and the test succeeded, so it must really be the kernel eating away a few megs. Alex - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
magic device renumbering was -- Re: Linux 2.4.2ac20
The problem: drivers change their detection schemes; and changes in the kernel can change the order in which devices are assigned names. For example, the DAC960(?) drivers changed their order of detecting controllers, and I did _not_ have fun, given that the machine in question had about 40 disks to deal with, spread across two controllers. This can create a lot of problems for people upgrading large, production quality systems -- as, in the worst case, the system won't complete the boot cycle; or in middle cases, the user/sysadmin is stuck rewriting X amount of files and trying again; or in small cases, you find out that your SMC and Intel ethernet cards are reversed, and have to go fix things ... Possible solutions(?): Solaris uses an /etc/path_to_inst file, to keep track of device ordering, et al. Maybe we should consider something similar, where a physical device to logical device map is kept and used to keep things consistent on kernel/driver changes; device addition/removal, and so forth ... I am, of course, open to better solutions. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 5Mb missing...
Jonathan Morton wrote: > > >> If crashes are routine on this machine, I'd recommend that you take > >> a serious look at your ram. (or if you're overclocking, don't) > > > >Crashes were routine, and I was not overclocking, so I took Mike's > >advice and bought a new 256MB DIMM. The computer hasn't crashed > >once since I installed it. Now, though, I have a curious though > >fairly irrelevant problem. My kernel apparently sees less RAM than > >I have. > > The kernel itself takes up some RAM, which is simply subtracted from the > "total memory available" field in the memory summaries available to > user-mode processes. This is perfectly normal. The kernel reserves 4m for hilself. The off by one error is a rounding bug. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac20
David Balazic wrote: > > Nathan Walp wrote: > > > > David Balazic wrote: > > > > > > Nathan Walp ([EMAIL PROTECTED]) wrote : > > > > > > > Also, sometime between ac7 and ac18 (spring break kept me from testing > > > > stuff inbetween), i assume during the new aic7xxx driver merge, the > > > > order of detection got changed, and now the ide-scsi virtual host is > > > > host0, and my 29160N is host1. Is this on purpose? It messed up a > > > > bunch of my stuff as far as /dev and such are concerned. > > > > > > SCSI adapters are enumerated randomly(*) , relying on certain numbering > > > will get you into trouble, sooner or later. > > > There is no commonly accepted solution, AFAIK. > > > The same thing can happent to disk enumeration ( sdb becomes sdc ) > > > or partition enumeration ( hda6 becomes hda5 ). > > > > > > * - theoreticaly no, but practicaly yes ( most of the time ) > > > > > > -- > > > David Balazic > > > -- > > > "Be excellent to each other." - Bill & Ted > > > - - - - - - - - - - - - - - - - - - - - - - > > > > SCSI adapters are given host numbers in a random order? Even with no > > hardware changes? Does this make less than sense to anyone else? Every > > kernel EVER up till now has had the real scsi cards (in some particular > > order) then ide-scsi. Have I just been lucky??? > > > > Nathan > > What I mean that too many factors are affecting the enumeration, > so that you can not rely on it : > > - kernel changes > - driver changes ( partly overlaps with the previous poit ) > - hardware changes > - something else ? > > There is no policy for this enumeration ( AFAIK ) , so there is > nothing to rely on , except luck :-) See, that all makes sense. You can't depend on hardware to detect in the same order, whether it's SCSI cards, network cards, or anything really. But the software psuedo-device that is ide-scsi, shouldn't that pick a spot before or after the hardware and stay there? That's my point, i guess. Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Bond driver on kernel-2.4.2
Hi, I'm trying to use a bond device using two (2) ethernet NICs for two RH Linux nodes. The link between the 2 Linux nodes is made it using 2 crossover cables for each NIC. I did not find any additional docs for this except kernel help and something in iputils package and probably I'm going wrong somewhere, because after the devices (bond and ethXX) are up when I try to ping the other node I got a lot of lost packages and the speed don't seems to be improved. I'm using RedHat 6.2 with iputils-20001010-1.6x.rpm and 2.4.2-kernel with bond driver built-in. Here are the settings for one of nodes (the other is almost the same except IPs): /etc/sysconfig/network-scrips/ifcfg-bond0: DEVICE=bond0 USERCTL=no ONBOOT=yes BOOTPROTO=none BROADCAST=192.168.1.255 NETWORK=192.168.1.0 NETMASK=255.255.255.0 IPADDR=192.168.1.198 /etc/sysconfig/network-scrips/ifcfg-eth0: DEVICE=eth0 USERCTL=no ONBOOT=yes MASTER=bond0 SLAVE=yes BOOTPROTO=none /etc/sysconfig/network-scrips/ifcfg-eth1: DEVICE=eth1 USERCTL=no ONBOOT=yes MASTER=bond0 SLAVE=yes BOOTPROTO=none /etc/host.conf order hosts, bind multi on The /etc/hosts file contains the IPs for each of the nodes on both. I have to mention that I cannot even open any TCP connection between nodes which in normal case (without bond interface) is possible. Any help will be highly appreciated, Thank you -- Adrian Turcu System Administrator - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sound problems with Asus K7V board using the via82cxxx drivers (2.4.3-pre 3/4)
I have the same problem with my K7VZA board. I replaced the onboard sound with a real card for now. - Original Message - From: "jens" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, March 13, 2001 10:02 PM Subject: Sound problems with Asus K7V board using the via82cxxx drivers (2.4.3-pre 3/4) > Hi there, I am not sure if this is a kernel problem or an operator > problem but for some reason or other my sound is no longer working. > More specifically when I run gmix it reports no mixers being found. I > verified that the via82cxxx driver is compiled in (it worked before) > and everything seems cosher. If anyone has a clue what would cause my > lack of sound, I would be grateful. > > Jens > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 5Mb missing...
>> If crashes are routine on this machine, I'd recommend that you take >> a serious look at your ram. (or if you're overclocking, don't) > >Crashes were routine, and I was not overclocking, so I took Mike's >advice and bought a new 256MB DIMM. The computer hasn't crashed >once since I installed it. Now, though, I have a curious though >fairly irrelevant problem. My kernel apparently sees less RAM than >I have. The kernel itself takes up some RAM, which is simply subtracted from the "total memory available" field in the memory summaries available to user-mode processes. This is perfectly normal. -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) -END GEEK CODE BLOCK- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [RFC] fbdev & power management
On Wed, 14 Mar 2001, Benjamin Herrenschmidt wrote:
> >> Either that, or the fbdev would register with PCI (or whatever), _and_
> >> fbcon would too independently. In that scenario, fbcon would only handle
> >> things like disabling the cursor timer, while fbdev's would handle HW
> >> issues. THe only problem is for fbcon to know that a given fbdev is
> >> asleep, this could be an exported per-fbdev flag, an error code, or
> >> whatever. In this case, fbcon can either buffer text input, or fallback
> >> to the cfb working on the backed up fb image (that last thing can be
> >> handled entirely within the fbdev I guess).
> >
> >I'd go for a fallback to dummycon. It's of no use to waste power on creating
> >graphical images of the text console when asleep. And the fallback to
> dummycon
> >is needed anyway while a fbdev is opened (in 2.5.x).
>
> We do already have the backup image since we need to backup & restore the
> framebuffer content.
Fine. Keep it. But there's no reason to keep on updating it when the screen
contents change. Fbcon can do that when the fbdev goes out of sleep mode.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: ISAPNP :driver not recognized when compiled in kernel
[EMAIL PROTECTED] wrote: > > Hello, >I have a basic question. Can we build a PnP ISA driver in kernel > with ISAPNP kernel option enabled so that kernel PnP does the job of > allocating the resources for the driver. The problem being that the > /etc/isapnp.conf should be executed before the device driver. I tried this > and was unsuccessful but worked fine when the driver was compiled as a > module. I read somewhere that ISAPNP drivers with ISAPNP enabled in kernel > should only be build as modules so that we can keep the order of execution > . Is this true.? Have any one of you tried this . > > Thanks & Regards > Shiju If you build ISAPnP support into the kernel you should not be using the isapnp userspace tools. Use on or the other, but not both. The ISAPnP system when non-modular is initialized before built-in drivers, so they do not have to be modular. With the old userspace tools they must be modular. -- Brian Gerst - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
