RE: LANANA: To Pending Device Number Registrants
At 11:56 AM +0200 2001-05-16, Chemolli Francesco (USI) wrote: We could do something like baptizing disks.. Fix some location (i.e. the absolutely last sector of the disk or the partition table or whatever) and store there some 32-bit ID (could be a random number, a progressive number, whatever). Most of these solutions (and RAID IDs and UUIDs) don't completely solve the problem; they just push it to a different time: how do you talk about a new disk, or a new RAID array, or a moved disk? And what about removable media (not neglecting the possibility of multiple drives)? Removable media from another OS? Shared drives? Not that this kind of firm ID might not be an improvement, or at least a good sanity check. [Side question, not original with me: why isn't all this a 2.5 discussion?] -- /Jonathan Lundell. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops with 2.4.3-XFS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
However, in testing a directory with lots (~177000) of files, we get the
following oops (copied by hand, and run through ksymoops on a Red Hat box
since the Debian one segfaulted :( )
Can you describe your testing beyond using a directory with 177000 files
in it?
Also, can you explain how you obtained the xfs code, from a patch, from
the cvs development tree, or from somewhere else?
Certainly :) (have been investigating further through the day)
The code was obtained as the patches for 2.4.3, (it was also patched for a
scsi changer, but all the scsi stuff is modules that weren't loaded), and
we used your Red Hat ISO in rescue mode to convert our root partition to
XFS.
I'd been trying to hammer a partition remotely. I'd exported it with
knfsd, but the oops I posted was caused by trying to tar said directory
(locally--no NFS involvement) to a file in its parent (which does contain
some large (~4GB) files.
kernel built with egcs-1.1.2, not very much in it, modules loaded at the
time were nfs, sunrpc, lockd, autofs (but I will test again without any of
those loaded when the box is less busy)--I had removed nfsd and friends.
We tried to recreate this on a second box a couple of hours ago and
failed, so we can't rule out a hardware/other non-XFS problem. Two
immediate potential culprits are the VIA KT133 UDMA and the drive itself
(NB the second box has the same motherboard, but not a WDC drive):
# hdparm -i /dev/hda
/dev/hda:
Model=WDC WD400BB-00AUA1, FwRev=18.20D18, SerialNo=WD-WMA6R1239029
Config={ HardSect NotMFM HdSw15uSec SpinMotCtl Fixed DTR5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40
BuffType=3(DualPortCache), BuffSize=2048kB, MaxMultSect=16, MultSect=off
DblWordIO=no, OldPIO=2, DMA=yes, OldDMA=0
CurCHS=4047/16/255, CurSects=16511760, LBA=yes, LBAsects=78165360
tDMA={min:120,rec:120}, DMA modes: mword0 mword1 mword2
IORDY=on/off, tPIO={min:120,w/IORDY:120}, PIO modes: mode3 mode4
UDMA modes: mode0 mode1 mode2 mode3 *mode4 mode5
Thanks for the reply. Any more information on request :)
Matt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7Apqx1vU/2MhEp5cRAgecAJ0bAm1Jlay2AjHjGaQ1Zck7/1vOewCgujgD
mAnEXzuyabuUwcPy22e1avM=
=41+h
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
At 4:57 PM +0200 2001-05-16, Vojtech Pavlik wrote: On Wed, May 16, 2001 at 07:37:45AM -0700, Jonathan Lundell wrote: At 10:02 AM +0200 2001-05-16, Vojtech Pavlik wrote: It's also true that some buses simply don't yield up physical locations (ISA springs to mind, ISA is quite fine, you can use the i/o space as physical locations. I meant physical not as in physical-vs-virtual addresses (all ISA addresses, memory or IO, are physical in this sense, by the time they get to the bus). Rather, I meant that you can't determine which slot a given device is plugged into. If you have two NICs in two ISA slots, there's no way to distinguish between the slots. In practice, you'd have to experiment or remove a card and check the jumpering or some such. Yes. But I meant that while this indeed is not possible, still the i/o port address can be used instead of the slot number, because it at least is physically jumpered and must be unique. Yes, I agree. And it's stable (whereas physical PCI addresses are not). Best we've got for ISA (though it's true for ISA memory addresses as well). -- /Jonathan Lundell. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ide-floppy
Hi, Whenever I boot (2.4.4-ac6) I get this error message if there is a zip disk in the drive. hdb: 98288kB, 196576 blocks, 512 sector size, hdb: 98304kB, 96/64/32 CHS, 4096 kBps, 512 sector size, 2941 rpm ide-floppy: hdb: I/O error, pc = 5a, key = 5, asc = 24, ascq = 0 The drive seems to work fine for everything except writing large files (500k) - umount hangs indefinitely. This has been a problem for all the kernels I've used since I got the drive (2.2.18, 2.2.20, 2.4.0-2.4.4-ac6 series). The ide-floppy support is compiled into the kernel but I've had similar problems when using it as a module. The disks work perfectly on a windows box and even worked fine when I was using the drive with windows. Can anyone shed any light on this for me? Thanks, Mark Phalan ps Could you cc replies to this address as I am not on the mailing list. Thanks. - 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-lvm] LVM 1.0 release decision
On Wed, 16 May 2001, Heinz J. Mauelshagen wrote: Linus, Alan et al.: maybe you could think about it again and accept one larger LVM patch. Thanks. I'm all for it right now. I'm running LVM on practically all my machines and would really like to have the latest bugfixes in my kernel ;) Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yesterday, Timothy A. Seufert ([EMAIL PROTECTED]) wrote: Why not take it a step further than just devices? This is a perfect model for supporting named forks. Because this only works on filesystems where directories can't themselves have named forks (or streams, or whatever you wish to call them) associated with them. Read the archives on this issue :) Mo. - -- Mo McKinlay [EMAIL PROTECTED] http://ekto.org Read http://www.ietf.org/rfc/rfc1855.txt - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.5 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjsCod0ACgkQRcGgB3aidflJyQCfdjh+o8vZvzZLfowM5QoLGICy tmAAoMIF4DcyqTep43Hd2/9X9tfeIH9X =cKMC -END PGP SIGNATURE- - 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: Bad udelay usage in drivers/net/aironet4500_card.c
On Wed, May 16, 2001 at 05:33:12AM -0700, Jalaja Devi wrote: Hi! Could you please tell me how you fixed the udelay problem. cuz, I am encountering the same problem in my driver. I am not a kernel expert. You should ask it on the kernel mailing list. Thanks for your time, Jalaja In 2.4.4, drivers/net/aironet4500_card.c has # grep udelay linux/drivers/net/aironet4500_card.c udelay(1000); udelay(100); udelay(10); udelay(10); udelay(20); udelay(25); udelay(1); udelay(1); udelay(1000); udelay(1000); udelay(1); But on ia32, you cannot use more than 2 for udelay (). You will get undefined symbol, __bad_udelay. __ 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/
Possible race in interruptible_sleep_on_timeout()
I lifted the following kernel-thread code from
../linux/drivers/net/8139too.c, just added a procedure to call.
static int gpib_thread(void *unused)
{
unsigned long timeout;
daemonize();
spin_lock_irq(current-sigmask_lock);
sigemptyset(current-blocked);
recalc_sigpending(current);
spin_unlock_irq(current-sigmask_lock);
memcpy(current-comm, task_name, sizeof(task_name));
for(;;)
{
timeout = 0x02;
do {
timeout = interruptible_sleep_on_timeout(info-twait, timeout);
} while (!signal_pending(current)(timeout 0));
if(signal_pending(current))
up_and_exit(info-quit, 0);
tinker(info-what_to_do);
}
}
It has been observed that, given the conditions of little or no
CPU activity except `top`, procedure tinker() will never get
executed because interruptible_sleep_on_timeout returns the
same timeout value it received.
This is on kernel version 2.4.1. Maybe this race has been found and
fixed?
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: LANANA: To Pending Device Number Registrants
Hi HPA, Linus, Alan, On Mon, May 14, 2001 at 12:19:34PM -0700, H. Peter Anvin wrote: Linus Torvalds has requested a moratorium on new device number assignments. His hope is that a new and better method for device space handing will emerge as a result. Alan Cox has requested that I maintain a forked registry for his -ac kernel patch tree. I have agreed to do so once I have forked off the final version of the registry for Linus' tree. [...] I've been following the discussion and would like to throw in my few cents. First of all, I see perfectly Linus' point of disliking the manual maintenance of device numbers. As the current solution is not elegant and requires a lot of work by the device registrar and probably more and more work in the future, this should be replaced by a better - automatic and elegant - mechanism in the future. Point taken. But I'm really surprised reading that the device registry is about to close now. Well, we need the better mechanism, before doing so. At first sight, devfs looks like the solution to this. But, on a second sight, devfs looks like a compromise between a new system, which would completely abstract the details of the underlying hardware and just present the devices from a user interface point of view, and the current system. We get rid of static major/minors, but the naming scheme still imposes to know lots of details about the way your hardware is plugged together. Furthermore, it seems, many people dislike devfs a lot. Instead of fixing a few problems with devfs or (more likely) with devfsd, they seem to believe the concept is fundamentally broken, otherwise their behaviour could only be considered ridiculous. So, we currently don't have a solution to this problem. A lot of good ideas have been proposed in this thread, but no working code that addresses all the issues (autoloading of modules, repeatability of naming, devices needed early in boot stage, ...) is there or was at least designed to a point where implementation is just a question of writing it down. Furthermore, some userspace apps use the major no to determine the exact type of a (otherwise similar) device to decide what functionality to offer or how to implement certain operations. In short: This change breaks currently working things. This can all be fixed, of course, but I doubt it can happen in very short time. To be honest, I fail to believe that such a policy change is happening now, in the middle of a stable kernel series, and I fail to believe that this is really what Linus suggested. IMHO, this policy change affects the kernel more than a major rework of VM, to just give an example. It's very definitely not stuff for 2.4. As far as I know, HPA has not complained about his workload for the manual maintenance of the the LANANA. Currently, it still seems doable, and HPA is doing it, fortunately. Thanks! I've not seen anybody complain about the way he does it either. So, I would be very pleased if we could agree, that it's acceptable to go on with the old manual device registry of HPA for the rest of the 2.4 kernel series. Let's start the new policy with 2.5.1! And please no fork! Every fork splits the community in two parts and basically halves our power. I don't think this would help Linux to be accepted by more people or to be able to be used to solve more problems in a nice and efficient way. I think I do very well understand one of the reasons, why Alan wants to stay with the old scheme. It (still) works. How would you imagine to make a stable Linux distribution, if such a change happens now? I do not think that all apps can be fixed and a stable, reproducible and reliable mechanism to manage device nodes can be introduced within the time frame of 2.4 kernels. Even switching a distro to use devfs only looks easier than this. So, we would need to keep to the old mechanism, if we don't want to risk stability and manageability of a distro. Which is paramount ... I would not like to be forced to use -ac kernels. (Alan, don't get this wrong! It's great that you prepare kernels to test somewhat more experimental features or drivers, but I would like to have the choice.) If we start the new device management with 2.5.1, there's plenty of time to have the mechanism and the kernel stabilize, to get issues like automatic module loading sorted and to adapt distributions before 2.6/3.0 comes out. That's fine with me. Well, maybe you never considered applying this policy change right now within 2.4, Linus. Well, ignore my posting then, if you like. Best regards, -- Kurt Garloff [EMAIL PROTECTED] [Eindhoven, NL] Physics: Plasma simulations [EMAIL PROTECTED] [TU Eindhoven, NL] Linux: SCSI, Security [EMAIL PROTECTED] [SuSE Nuernberg, FRG] (See mail header or public key servers for PGP2 and GPG public keys.) PGP signature
Re: rwsem, gcc3 again
Andrea, I doubt that it applies against -ac and I have only very few hard disk space, so please don't beat me I could not try... (I tried the second-to-last but it didn't apply either) But 2.4.3-ac7 works very fine with your older patch. As noticed, I now solved by CONFIG_RWSEM_GENERIC_SPINLOCK=y (as in i386) by hand on i686. Sorry -mirabilos -- by telnet - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On 16 May 2001 15:28:03 +0200, Helge Hafting wrote: Oystein Viggen wrote: Quoth Helge Hafting: This could be extended to non-raid use - i.e. use the raid autodetect partition type for non-raid as well. The autodetect routine could then create /dev/partitions/home, /dev/partitions/usr or /dev/partitions/name_of_my_choice for autodetect partitions not participating in a RAID. What happens if I insert a hard drive from another computer which also has partitions named home, usr, and soforth? This is the problem with all sorts of ID-based naming. In this case the kernel could simply change the conflicting names a bit, and leave the cleanup to the administrator. (Who probably is around as he just inserted those disks) The current scheme have problems if you move a disk from one controller to another, or in some cases if you merely add a new one. So the question becomes - what is most likely to go wrong? And you can be smart and name your partitions /usr21042001, /home03042001 and so on in order to minimize the risk of conflicts. Well, a usermode solution might be to add support for having the filesystem utilities generate and detect partition IDs. Then the disks could be moved from one controller to another, but mount could scan partition IDs and associate mount points on matching IDs rather than on /dev/hdX or /dev/sdX. Or is this a ridiculous idea? Miles - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Wed, May 16, 2001 at 09:30:46AM -0700, Miles Lane wrote: On 16 May 2001 15:28:03 +0200, Helge Hafting wrote: Oystein Viggen wrote: Quoth Helge Hafting: This could be extended to non-raid use - i.e. use the raid autodetect partition type for non-raid as well. The autodetect routine could then create /dev/partitions/home, /dev/partitions/usr or /dev/partitions/name_of_my_choice for autodetect partitions not participating in a RAID. What happens if I insert a hard drive from another computer which also has partitions named home, usr, and soforth? With the current LABEL= support, you won't be able to mount the disks with duplicate labels, but you can still mount them via /dev/sdxxx. Obviously, you need an escape hatch to do this. I ran into this with having two root partitions (to support multiple distributions or releases of distributions), where the distribution automatically uses LABEL=. Fortunately, it was fairly easy to use e2label to fix things up. This is the problem with all sorts of ID-based naming. In this case the kernel could simply change the conflicting names a bit, and leave the cleanup to the administrator. (Who probably is around as he just inserted those disks) The current scheme have problems if you move a disk from one controller to another, or in some cases if you merely add a new one. So the question becomes - what is most likely to go wrong? And you can be smart and name your partitions /usr21042001, /home03042001 and so on in order to minimize the risk of conflicts. Well, a usermode solution might be to add support for having the filesystem utilities generate and detect partition IDs. Then the disks could be moved from one controller to another, but mount could scan partition IDs and associate mount points on matching IDs rather than on /dev/hdX or /dev/sdX. I don't see how this is any different from the current LABEL= support that is currently in the ext2 filesystem (except I seem to recall that it doesn't work on devfs). Of course it would be useful for /proc/partitions to provide the label IDs and UUIDs. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Tue, May 15, 2001 at 01:18:09PM -0700, Linus Torvalds wrote: On Tue, 15 May 2001, Jonathan Lundell wrote: Keep it informational. And NEVER EVER make it part of the design. What about: 1 (network domain). I have two network interfaces that I connect to two different network segments, eth0 eth1; So? Informational. You can always ask what eth0 and eth1 are. There's another side to this: repeatability. A setup should be _repeatable_. This is what we have now. Network devices are called eth0..N, and nobody is complaining about the fact that the numbering is basically random. It is _repeatable_ as long as you don't change your hardware setup, and the numbering has effectively _nothing_ to do with location. Well yes and no. The numbers are currently repeatable for a given kernel, but I know I and others were bitten by the 2.2. to 2.4 transition, where the kernel used a different algorithm for the order in which it detected scsi and network adapters (ie, in my machine with 3 scsi adapters, Linux 2.2 always picked the Adaptec scsi adapter builtin into my motherboard as the first adapter, but 2.4 decided to pick my TekRam 390F adapter). As lots of people have been saying, you need to know which physical slot to plut the wire connecting eth0, eth1, etc. into. Similarly for serial ports, if I have 3 or 4 (or 127 :-) USB serial devices, I really don't want to have to change my cabling each time I boot or change OSes (since I doubt my UPS will be happy if I give it the commands destined for the X10 controller or my remote boards). -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Getting FS access events
Anton Altaparmakov wrote: True, but I was under the impression that Linus' master plan was that the two would be in entirely separate name spaces using separate cached copies of the device blocks. Nothing was said about the superblock at all. -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! Unix gives you enough rope to shoot yourself in the foot. http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: export linux_logo_bw for hgafb.c
On Wed, May 16, 2001 at 03:41:40PM +0200, Geert Uytterhoeven wrote:
On Tue, 15 May 2001, H . J . Lu wrote:
Here is a patch for 2.4.4. linux_logo_bw is used in hgafb.c, which
can be compiled as a module. But linux_logo_bw is not exported.
linux_logo_bw is __initdata.
How about this patch?
H.J.
---
--- linux-2.4.4-ac9/drivers/video/fbcon.c.logo Wed May 16 09:40:33 2001
+++ linux-2.4.4-ac9/drivers/video/fbcon.c Wed May 16 09:41:12 2001
@@ -97,6 +97,7 @@
#include asm/io.h
#endif
#define INCLUDE_LINUX_LOGO_DATA
+#define INCLUDE_LINUX_LOGOBW
#include asm/linux_logo.h
#include video/fbcon.h
--- linux-2.4.4-ac9/include/linux/linux_logo.h.logo Wed May 16 09:20:41 2001
+++ linux-2.4.4-ac9/include/linux/linux_logo.h Wed May 16 09:23:17 2001
@@ -912,93 +912,6 @@ unsigned char linux_logo[] __initdata =
#endif /* !__HAVE_ARCH_LINUX_LOGO */
-#ifndef __HAVE_ARCH_LINUX_LOGOBW
-
-unsigned char linux_logo_bw[] __initdata = {
-0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0xf0, 0x0f, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0xcf, 0xf3, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0xbf, 0xfc, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0x7f, 0xff, 0x7f, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfe, 0xff, 0xff, 0xbf, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfd, 0xff, 0xf3, 0xdf, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfd, 0xff, 0xf7, 0xef, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfd, 0xff, 0xff, 0xef, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0xff, 0xff, 0xef, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0xff, 0xff, 0xf7, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0xff, 0xff, 0xf7, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0xff, 0xff, 0xf7, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0x9f, 0x87, 0xfb, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0x0f, 0x03, 0xfb, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0x67, 0x33, 0xfb, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0xe7, 0x79, 0xfb, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0xf7, 0x79, 0xfb, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0xff, 0xf9, 0xf7, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0x60, 0x3b, 0xf7, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0x89, 0x07, 0xfb, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0x00, 0x03, 0xfb, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0x00, 0x0d, 0xfb, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0x80, 0x33, 0xfd, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0xc0, 0xc3, 0xfd, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0xff, 0x0d, 0xdd, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0x40, 0x31, 0xee, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xf7, 0x20, 0xc1, 0xee, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xf7, 0x1f, 0x00, 0xff, 0x7f, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xef, 0x00, 0x00, 0x7f, 0xbf, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xee, 0x00, 0x00, 0x7f, 0xbf, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xde, 0x00, 0x00, 0x7f, 0xdf, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xbc, 0x00, 0x00, 0x3f, 0xef, 0xff, 0xff,
-0xff, 0xff, 0xff, 0x7c, 0x00, 0x00, 0x3f, 0xf7, 0xff, 0xff,
-0xff, 0xff, 0xff, 0x7c, 0x00, 0x00, 0x1f, 0xf7, 0xff, 0xff,
-0xff, 0xff, 0xfe, 0xff, 0x1c, 0x07, 0xdf, 0xfb, 0xff, 0xff,
-0xff, 0xff, 0xfd, 0xfc, 0x08, 0x0f, 0xef, 0xfd, 0xff, 0xff,
-0xff, 0xff, 0xfd, 0xf8, 0x00, 0x01, 0xef, 0xfd, 0xff, 0xff,
-0xff, 0xff, 0xfb, 0xf0, 0x00, 0x00, 0x7f, 0xfe, 0xff, 0xff,
-0xff, 0xff, 0xfb, 0xe0, 0x00, 0x00, 0x1f, 0xfe, 0xff, 0xff,
-0xff, 0xff, 0xf7, 0xe0, 0x00, 0x00, 0x07, 0xbf, 0x7f, 0xff,
-0xff, 0xff, 0xf7, 0xc0, 0x00, 0x00, 0x03, 0xbf, 0x7f, 0xff,
-0xff, 0xff, 0xef, 0xc0, 0x00, 0x00, 0x03, 0xdf, 0xbf, 0xff,
-0xff, 0xff, 0xef, 0x80, 0x00, 0x00, 0x03, 0xdf, 0xbf, 0xff,
-0xff, 0xff, 0xdf, 0x80, 0x00, 0x00, 0x03, 0xdf, 0xbf, 0xff,
-0xff, 0xff, 0xdf, 0x80, 0x00, 0x00, 0x01, 0xef, 0xdf, 0xff,
-0xff, 0xff, 0xdf, 0x80, 0x00, 0x00, 0x01, 0xef, 0xdf, 0xff,
-0xff, 0xff, 0xbf, 0x00, 0x20, 0x00, 0x01, 0xef, 0xdf, 0xff,
-0xff, 0xff, 0xbf, 0x00, 0x20, 0x00, 0x01, 0xef, 0xdf, 0xff,
-0xff, 0xff, 0xbf, 0x00, 0x20, 0x00, 0x01, 0xef, 0xdf, 0xff,
-0xff, 0xff, 0xbf, 0x00, 0x20, 0x00, 0x01, 0xef, 0xdf, 0xff,
-0xff, 0xff, 0xbf, 0x00, 0x20, 0x00, 0x03, 0x03, 0xdf, 0xff,
-0xff, 0xff, 0xbf, 0x00, 0x20, 0x00, 0x02, 0xfd, 0xdf, 0xff,
-0xff, 0xff, 0xa3, 0x80, 0x00, 0x00, 0x1f, 0xff, 0xdf, 0xff,
-0xff, 0xff, 0xc1, 0xc0, 0x00, 0x00, 0x11, 0xff, 0x3f, 0xff,
-0xff, 0xff, 0x80, 0xe0, 0x00, 0x00, 0x21, 0xfe, 0x3f, 0xff,
-0xff, 0xff, 0x00, 0x70, 0x00, 0x00, 0x21, 0xfc, 0x3f, 0xff,
-0xff, 0xfe, 0x00, 0x3c, 0x00, 0x00, 0x20, 0xf8, 0x3f, 0xff,
-0xff, 0xf0, 0x00, 0x3e, 0x00, 0x00, 0x20, 0x00, 0x3f, 0xff,
-0xff, 0xc0, 0x00, 0x1f, 0x00, 0x00, 0x20, 0x00, 0x3f, 0xff,
-0xff, 0xc0, 0x00, 0x1f, 0x80, 0x00, 0x20, 0x00, 0x1f, 0xff,
-
Re: LANANA: To Pending Device Number Registrants
At this point of the discussion I would like to point to the Device Registry patch (http://www.tjansen.de/devreg) that already solves these problems and offers stable device ids for the identification of devices and finding their /dev nodes. Does your approach solve the problem of USB devices, like mice, that don't have device ID's of any sort, where topology is the only way to distinguish them? IIRC, the USB development team was planning to use topology to provide a limited ability to associate a mouse on a given port with a display, when XFree86 supports per-Xinerama-display input device associations. They new VT console work would benefit from this, too. I have been thinking about this. If you think about it multi-desktop systems are very similar to clustering. The idea is something can only be seen by certain things in the system. With clustering you might want a shared memeory segment (/dev/shm) visble to certain NUMA nodes. With multi-desktop systems you have several users using the same box. Now you don't want to user 3 being able to draw something to users 2 screen. So how do you handle this? Since we are treating the device as a filesystem we can control the permissons on all the files in the filesystem. This gives the extra bonus of the ability to make certain device features global to certain groups. The best way I can see it is to setup workstation groups. This is pretty easy to do with most systems since most have a group per user. So for desktop one you have it belong to user joe. So when he want to some device on his machine he mounts the filesystem and all the files and directories belong to joe. No one else can use that device. Now what if you want several people to be able to use the same desktop. The sys admin could create a desktop1 group and then ensure the device is mounted with the desktop1 group. Then anyone belonging to the desktop group can access this hardware. The extra bonus is the ability to allow certain feature of a device to be exposed to same someone in your group. This could be a really powerful feature. Unfortunely I can't think of a example off the top of my head. - 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: RH 7.1 on IBM xSeries 240
This may be way off, but have you flashed the BIOS to the most current revision? This machine should work properly. How many processors and what SR card are you using? ps ([EMAIL PROTECTED]) [010516 03:07]: - I'm trying to run Linux RH 7.1 on the rack-mounted - IBM xSeries 240 with ServeRAID but without success. - I've tried some kernels from 2.2.19-7.0.1smp up to - 2.4.3-2.14.14.i686 and 2.4.4. - - During boot all kernels reported errors (attached at the end). - When I try to write to disk (untar 100MB) machine almost hangs - - I must wait MINUTES for any simple ll or who. - - Thanks in advance for any help. - - - Piotr Szymanek - - = - ... - - found SMP MP-table at 0009e140 - hm, page 0009e000 reserved twice. - hm, page 0009f000 reserved twice. - hm, page 000a reserved twice. - hm, page 0009e000 reserved twice. - hm, page 0009f000 reserved twice. - hm, page 000a reserved twice. - WARNING: MP table in the EBDA can be UNSAFE - - ... - - ENABLING IO-APIC IRQs - ...changing IO-APIC physical APIC ID to 14 ... ok. - BIOS bug, IO-APIC#1 ID is 15 in the MPC table!... - ... fixing up to 15. (tell your hw vendor) - ...changing IO-APIC physical APIC ID to 15 ... ok. - Synchronizing Arb IDs. - init IO_APIC IRQs - IO-APIC (apicid-pin) 14-0, 14-5, 15-0, 15-1, 15-2, 15-3, 15-14, 15-15 - not connected. - ..TIMER: vector=49 pin1=2 pin2=0 - ..MP-BIOS bug: 8254 timer not connected to IO-APIC - ...trying to set up timer (IRQ0) through the 8259A ... - . (found pin 0) ...works. - number of MP IRQ sources: 31. - number of IO-APIC #14 registers: 16. - number of IO-APIC #15 registers: 16. - testing the IO APIC... - - ... - - CPU1T0:1332736,T1:444240,D:6,S:444245,C:1332737 - checking TSC synchronization across CPUs: passed. - Setting commenced=1, go go go - mtrr: your CPUs had inconsistent fixed MTRR settings - mtrr: probably your BIOS does not setup all CPUs - PCI: PCI BIOS revision 2.10 entry at 0xfd34c, last bus=4 - - - 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/ I can't believe it's not UNIX!!! Leah Cunningham | SuSE Expert, NOS Engineer, Undisclosed Address | QA Linux geek, et 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: LANANA: To Pending Device Number Registrants
On Wed, May 16, 2001 at 02:09:32PM +0200, Thomas Kotzian wrote: From: Helge Hafting [EMAIL PROTECTED] Partition id's seems more interesting than disk id's - we normally mount partitions not whole disks. RAID do this well - the raid autodetect partition stores an ID in the last block, the remaining N-1 blocks are available for a fs. This could be extended to non-raid use - i.e. use the raid autodetect partition type for non-raid as well. The autodetect routine could then create /dev/partitions/home, /dev/partitions/usr or /dev/partitions/name_of_my_choice for autodetect partitions not participating in a RAID. Raid can do this easily because they install the raid on fresh partitions so they can easily steal the last sector, and the filesystem goes in the shrinked raid-device. Normal partitions that already have a filesystem on them (maybe another OS formatted them) occupy space including the last sector - no place left on these partitions to baptize them. - how should that work with existing fs'es??? Right. LVM does a similar thing storing UUIDs in its private metadata area on every device used by it. Problem is: neither MD nor LVM define a standard in Linux which *needs* to be used on every device! It is just up to the user to configure devices with them or not. BTW: in case we had a Linux standard it wouldn't solve the different OS situation mentioned in this thread either. Generally speaking: It is not the problem to reserve some space to store a uuid or something at such and such location on a device. The problem is the lack of a standard which eventually could be implemented in all OSes at some point in time. OS dependent data migration tools presumed, we could have that standard in place on (all) real devices a little later than that ;-) And what about a standard to access the stored identifying data and to avoid that it doesn't get overwritten by accident? This is better than volume labels, as it will work for all fs'es (including those who don't support mount-by-ID) and also raw partitions with no fs. Thomas Kotzian - 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/ -- Regards, Heinz-- The LVM Guy -- *** Software bugs are stupid. Nevertheless it needs not so stupid people to solve them *** =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Heinz Mauelshagen Sistina Software Inc. Senior Consultant/Developer Am Sonnenhang 11 56242 Marienrachdorf Germany [EMAIL PROTECTED] +49 2626 141200 FAX 924446 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
So what is your solution for preventing a boot failure after disks/partitions change ? volume labels/UUID ? As a sys-admin, let me add a vote for this. Having (one day) a prom monitor program that looks at all the disks, and gives a menu of which one to boot from would make life so nice. I very often had to move disks from one platform to another, and changing ID's on the was hard or impossible in some cases, and required in others. Being able to find the disk by a label is a thousand times better. - 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/
NTFS with Win2k - Write Support broken?
Hallo, I have a linux system with kernel 2.4.4-ac9 and a win2k partition with ntfs. Since because of the new ntfs version rw support is disabled, I wondered how much rw support is broken, why and if I could try at least. Or maybe some help is appreciated? Thanks a lot, Axel Siebenwirth - 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] rootfs (part 1)
On Wed, 16 May 2001, Alexander Viro wrote: Linus, patch is the first chunk of rootfs stuff. I've tried to get it as small as possible - all it does is addition of absolute root on ramfs and necessary changes to mount_root/change_root/sys_pivot_root and follow_dotdot. Real root is mounted atop of the absolute one. Looks ok, but it also feels like 2.5.x stuff to me. Also, there's the question of whether to make ramfs just built-in, or make _tmpfs_ built in - ramfs is certainly simpler, but tmpfs does the same things and you need that one for shared mappings etc. Comments? Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
[EMAIL PROTECTED] (Hacksaw) writes: So what is your solution for preventing a boot failure after disks/partitions change ? volume labels/UUID ? As a sys-admin, let me add a vote for this. Having (one day) a prom monitor program that looks at all the disks, and gives a menu of which one to boot from would make life so nice. I very often had to move disks from one platform to another, and changing ID's on the was hard or impossible in some cases, and required in others. Being able to find the disk by a label is a thousand times better. Did you ever try grub?? This a gnu project, a boot-loader, with an embedded shell... You can read ext2fs and select, your kernel, your root disk, your params, etc... -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
mmap is fine for a fb, but please don't remove read/write. I can now do a screendump with cat /dev/fb/0 file, because everything is a file. Having /dev/fb/0/brightness /dev/fb/0/opengl and so on seems to be a better approach. One I like to name of the file system to be something else. This way apps can move over to it. You will still be able to do the above. I plan to have for each framebuffer /dev/gfx/frameX. So say your card can do double buffer you could do cat /dev/gfx/frame0 file1 cat /dev/gfx/frame1 file2 So you could access the double buffer as well :-) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.20pre2aa1
On Wed, 16 May 2001, Andrea Arcangeli wrote: On Tue, May 15, 2001 at 08:33:05PM -0700, dean gaudet wrote: apache since 1.3.15 has defined SINGLE_LISTEN_UNSERIALIZED_ACCEPT ... That's definitely a good thing. hmm, i'm not so sure -- 1.3.x is our stable release, and it sounds like this change has added an instability. 'cause that's what you guys asked me to do :) does this mean there are known hangs on linux 2.2.x without your fix? I never heard of anybody reproducing that but accpet() in 2.2 can _definitely_ miss events without the above 00_wake-one-4 patch because it wrongly considers a progress wakeing up two times the same exclusive task. i'm guessing from your description that the missed event will be noticed when the next socket arrives. i.e. if the server is pretty busy then the missed events are not important. but if it's not a busy server, like a hit every hour, then the missed event may be noticeable to browsers (as a timeout waiting for server activity). does that pretty much sum it up? Furthmore the exclusive wakeup logic with the exclusive information per-task and not per wait_queue_t will screwup if the tasks registers itself like a wakeall after it was just registered as wakeone somewhere else (however this second thing is more a theorical issue that shouldn't trigger in 2.2). i.e. if the socket was used both in accept() and in select() at the same time? (which apache doesn't do) thanks -dean - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Transmit time out on eth1 (rtl8139) / dirty entry in queue [again]
hi, this old problem I had been faced with had been solved with 2.4.3-ac13/14, but now with kernel 2.4.4-ac9 and all other 2.4.4-acx it came up again. It's a Realtek 8139C chip on a AT2500 (allied telesyn or sumpin like that) Instead the former Apr 24 16:16:57 bello kernel: eth1: Setting half-duplex based on auto-negotiated partner ability . I have now an unconnected cable which is not the fact:) May 16 15:20:26 bello kernel: eth1: media is unconnected, link down, or incompatible connection May 16 15:20:44 bello kernel: NETDEV WATCHDOG: eth1: transmit timed out May 16 15:20:44 bello kernel: eth1: Tx queue start entry 783 dirty entry 779. May 16 15:20:44 bello kernel: eth1: Tx descriptor 0 is 2000. May 16 15:20:44 bello kernel: eth1: Tx descriptor 1 is 2000. May 16 15:20:44 bello kernel: eth1: Tx descriptor 2 is 2000. May 16 15:20:44 bello kernel: eth1: Tx descriptor 3 is 2000. (queue head) May 16 15:20:44 bello kernel: eth1: media is unconnected, link down, or incompatible connection Could I adjust some values, like tx buffer to get it to work? Please excuse my unscientific nature. I can as well supply any more information about the scenario... Regards, Axel Siebenwirth - 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/
VIA/PDC/Athlon
I tested 2.4.4-ac9 today on A7V133 machine. It booted up, but can't stand any load. It will deadlock (without oops) when the network/disk system faces any load. There is also some new bug in VIA IDE driver. It misdetects cable as 80-w when it's only 40-w and causes some CRC errors and speed dropping. Some older kernels correctly detected the cable as 40-w and used UDMA33, this one tries to use UDMA100 and fails (of course). Is there any way to force cable detection to 40-w? - Jussi Laako -- PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B 39DD A4DE 63EB C216 1E4B Available at PGP keyservers - 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: RH 7.1 on IBM xSeries 240
Yes, I have the newest BIOS and SR Firmware. I have 2 x 1GHz CPUs and IBM PCI ServeRAID 4.71.00 ServeRAID 4L -- Piotr Szymanek Leah Cunningham wrote: This may be way off, but have you flashed the BIOS to the most current revision? This machine should work properly. How many processors and what SR card are you using? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.20pre2aa1
On Wed, May 16, 2001 at 10:25:32AM -0700, dean gaudet wrote: On Wed, 16 May 2001, Andrea Arcangeli wrote: On Tue, May 15, 2001 at 08:33:05PM -0700, dean gaudet wrote: apache since 1.3.15 has defined SINGLE_LISTEN_UNSERIALIZED_ACCEPT ... That's definitely a good thing. hmm, i'm not so sure -- 1.3.x is our stable release, and it sounds like this change has added an instability. Not if you use my 2.2 tree or any recent 2.4 out there. I mean that's not an apache mistake, you shouldn't backout that change because of a kernel race condition. i'm guessing from your description that the missed event will be noticed when the next socket arrives. i.e. if the server is pretty busy then the yes, it will handle the missed connect only when the next connect request arrives. missed events are not important. but if it's not a busy server, like a hit every hour, then the missed event may be noticeable to browsers (as a timeout waiting for server activity). does that pretty much sum it up? I'm not sure what apache does exactly while handling new connections but your above description of the sympthoms sounds ok. Furthmore the exclusive wakeup logic with the exclusive information per-task and not per wait_queue_t will screwup if the tasks registers itself like a wakeall after it was just registered as wakeone somewhere else (however this second thing is more a theorical issue that shouldn't trigger in 2.2). i.e. if the socket was used both in accept() and in select() at the same time? (which apache doesn't do) No because the same task cannot run accept() and select() at the same time, that's a per-task vs per-waitqueue_t issue (not per-socket), imagine it like accept() calling select() interally in the kernel, which doesn't happen of course and that's why it cannot trigger in real life, you cannot exploit it from userspace, it's a kernel internal issue. So don't worry about it ;) My patch has the bonus to fix it as well though (like 2.4). Andrea - 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: RH 7.1 on IBM xSeries 240
Well, if you want I can try and reproduce your issue once I have access to this machine. It may be about a week or so. RH 7.1 has been tested on this machine, but not with ServeRaid 4.71. ps ([EMAIL PROTECTED]) [010516 10:29]: - Yes, I have the newest BIOS and SR Firmware. - I have 2 x 1GHz CPUs and IBM PCI ServeRAID 4.71.00 ServeRAID 4L - --- Piotr Szymanek - - - Leah Cunningham wrote: - - This may be way off, but have you flashed the BIOS to the most - current revision? This machine should work properly. How many - processors and what SR card are you using? I can't believe it's not UNIX!!! Leah Cunningham | SuSE Expert, NOS Engineer, Undisclosed Address | QA Linux geek, et 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/
wrong /dev/sd... order with multiple adapters in kernel 2.4.4
Hi, I have recently upgraded the kernel from 2.2.19 to 2.4.4 and discovered that it assigns the /dev/sd... devices in the wrong order with respect both to the behavior of kernel 2.2.19 and to the `scsihosts' boot option which I specified at the boot prompt. I have a scsi-only machine with an Adaptec 7890 and an old Symbios 53c875. The Adaptec mounts an LVD disk with the root and home partitions while the Symbios mounts two additional disks used for other purposes: # cat /proc/pci Bus 0, device 6, function 0: SCSI storage controller: Adaptec AHA-2940U2/W / 7890 (rev 0). IRQ 11. Master Capable. Latency=32. Min Gnt=39.Max Lat=25. I/O at 0xd000 [0xd0ff]. Non-prefetchable 64 bit memory at 0xe080 [0xe0800fff]. Bus 0, device 9, function 0: SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c875 (rev 3). IRQ 11. Master Capable. Latency=144. Min Gnt=17.Max Lat=64. I/O at 0xb800 [0xb8ff]. Non-prefetchable 32 bit memory at 0xe000 [0xe0ff]. Non-prefetchable 32 bit memory at 0xdf80 [0xdf800fff]. # cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: FUJITSU Model: MAE3091LPRev: 0112 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 00 Lun: 00 Vendor: WDIGTL Model: ENTERPRISE Rev: 1.91 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 04 Lun: 00 Vendor: FUJITSU Model: MAE3091LPRev: 0112 Type: Direct-AccessANSI SCSI revision: 02 Since I want to use the kernel also in rescue diks I have compiled the needed scsi divers statically: CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_AIC7XXX=y CONFIG_SCSI_SYM53C8XX=y With kernel 2.2.19 the Adaptec is initialized first and it assigns /dev/sda to its only disk. With kernel 2.4.4 the Symbios is initialized first, /dev/sda is assigned to the wrong (for my purposes) disk and I'm not able to boot the system, unless I fix the fstab, which I don't want to do because I need to use it also with the old kernel 2.2.19. This is the relevant output from dmesg: Linux version 2.4.4 (root@nikita) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #1 Tue May 15 10:12:38 MEST 2001 PCI: PCI BIOS revision 2.10 entry at 0xf0720, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Using IRQ router PIIX [8086/7110] at 00:04.0 SCSI subsystem driver Revision: 1.00 scsi: host order: aic7xxx PCI: Found IRQ 11 for device 00:09.0 PCI: The same IRQ used for device 00:04.2 PCI: The same IRQ used for device 00:06.0 sym53c8xx: at PCI bus 0, device 9, function 0 scsi1 : sym53c8xx-1.7.3a-20010304 Vendor: WDIGTLModel: ENTERPRISERev: 1.91 Type: Direct-Access ANSI SCSI revision: 02 Vendor: FUJITSU Model: MAE3091LP Rev: 0112 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi1, channel 0, id 0, lun 0 Detected scsi disk sdb at scsi1, channel 0, id 4, lun 0 SCSI device sda: 8515173 512-byte hdwr sectors (4360 MB) /dev/scsi/host1/bus0/target0/lun0: p1 p2 SCSI device sdb: 17826240 512-byte hdwr sectors (9127 MB) /dev/scsi/host1/bus0/target4/lun0: p1 PCI: Found IRQ 11 for device 00:06.0 PCI: The same IRQ used for device 00:04.2 PCI: The same IRQ used for device 00:09.0 scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.5 Adaptec aic7890/91 Ultra2 SCSI adapter aic7890/91: Wide Channel A, SCSI Id=7, 32/255 SCBs Vendor: FUJITSU Model: MAE3091LP Rev: 0112 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sdc at scsi0, channel 0, id 0, lun 0 SCSI device sdc: 17826240 512-byte hdwr sectors (9127 MB) /dev/scsi/host0/bus0/target0/lun0: p1 p2 p3 p4 There is nothing wrong in this, the kernel must choose some ordering when initializing the devices and Symbios first is not worse than Adaptec first. The problem is that the new kernel accepts a boot option (scsihosts) to force the order in which the scsi devices are detected, but this option is completely ignored while detecting the /dev/sd... devices. Even specifying the boot option scsihosts=aic7xxx I get the following scsi assignments: /dev/scsi/host0/bus0/target0/lun0 /dev/sdc /dev/scsi/host1/bus0/target0/lun0 /dev/sda /dev/scsi/host1/bus0/target4/lun0 /dev/sdb which seems illogical to me because the device order is inconsistent between the two device naming schemes. This is also incompatible with the behavior of kernel-2.2.x. Also trying the `pci=bios' option doesn't help because the initialization order is determined not by the pci bus scan order but only by the ld order of the drivers when the kernel was compiled. The only way to solve my problem was to modify the makefiles and link the aic7xxx driver before the sym53c8xx, but this is a solution only for my
Re: [PATCH] rootfs (part 1)
Christoph Rohland wrote: Hi Linus, On Wed, 16 May 2001, Linus Torvalds wrote: Looks ok, but it also feels like 2.5.x stuff to me. Also, there's the question of whether to make ramfs just built-in, or make _tmpfs_ built in - ramfs is certainly simpler, but tmpfs does the same things and you need that one for shared mappings etc. Comments? cr:/speicher/src/u4ac9 $ ls -l mm/shmem.o* -rw-r--r--1 cr users 154652 Mai 16 19:27 mm/shmem.o-tmpfs -rw-r--r--1 cr users 180764 Mai 16 19:24 mm/shmem.o+tmpfs cr:/speicher/src/u4ac9 $ ls -l fs/ramfs/ramfs.o -rw-r--r--1 cr users 141452 Mai 16 19:27 fs/ramfs/ramfs.o So CONFIG_TMPFS adds 26k and ramfs 140k. On what system? I don't think this is a good measure... [jgarzik@rum linux_2_4]$ ls -l fs/ramfs/ramfs.o -rw-r--r--1 jgarzik jgarzik 5830 May 15 09:29 fs/ramfs/ramfs.o [jgarzik@rum linux_2_4]$ ls -l mm/shmem.o (includes tmpfs) -rw-r--r--1 jgarzik jgarzik 17496 May 15 09:28 mm/shmem.o -- Jeff Garzik | Game called on account of naked chick Building 1024| MandrakeSoft | - 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] rootfs (part 1)
Hi Linus, On Wed, 16 May 2001, Linus Torvalds wrote: Looks ok, but it also feels like 2.5.x stuff to me. Also, there's the question of whether to make ramfs just built-in, or make _tmpfs_ built in - ramfs is certainly simpler, but tmpfs does the same things and you need that one for shared mappings etc. Comments? cr:/speicher/src/u4ac9 $ ls -l mm/shmem.o* -rw-r--r--1 cr users 154652 Mai 16 19:27 mm/shmem.o-tmpfs -rw-r--r--1 cr users 180764 Mai 16 19:24 mm/shmem.o+tmpfs cr:/speicher/src/u4ac9 $ ls -l fs/ramfs/ramfs.o -rw-r--r--1 cr users 141452 Mai 16 19:27 fs/ramfs/ramfs.o So CONFIG_TMPFS adds 26k and ramfs 140k. Greetings Christoph - 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] rootfs (part 1)
On 16 May 2001, Christoph Rohland wrote: cr:/speicher/src/u4ac9 $ ls -l mm/shmem.o* -rw-r--r--1 cr users 154652 Mai 16 19:27 mm/shmem.o-tmpfs -rw-r--r--1 cr users 180764 Mai 16 19:24 mm/shmem.o+tmpfs cr:/speicher/src/u4ac9 $ ls -l fs/ramfs/ramfs.o -rw-r--r--1 cr users 141452 Mai 16 19:27 fs/ramfs/ramfs.o So CONFIG_TMPFS adds 26k and ramfs 140k. What the hell are you doing? Compiling with debugging or something? The ramfs inode.o file (the only file that ramfs contains) has 376 bytes of data and 1612 bytes of code. BYTES. The whole final object file with all the relocation information is -rw-r--r--1 torvalds eng 5734 May 16 10:58 ramfs.o but out of that 5.5kB, only 2kB are actually linked into the kernel and are used to _run_. How do you get it to 140kB? You're doing something _seriously_ wrong. You're off by a factor of 70. Linus - 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] rootfs (part 1)
Linus Torvalds wrote: What the hell are you doing? Compiling with debugging or something? I'll bet he's using a rootkit 'ls' that shows file sizes in bits. ;-) regards, David -- David L. Parsley Network Administrator, Roanoke College If I have seen further it is by standing on ye shoulders of Giants. --Isaac Newton - 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] move aic7xxx ld in drivers/scsi/Makefile
Hi, while examining the makefiles of kernel-2.4.4 I noticed that the top Makefile contains a specific reference to the aic7xxx driver which should IMHO be referenced only by the drivers/scsi/Makefile. This was changed post v6.1.5 of the aic7xxx driver. Apply the latest patch for 2.4.4 from here: http://people.FreeBSD.org/~gibbs/linux/ and see if this is satisfactory. -- Justin - 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: wrong /dev/sd... order with multiple adapters in kernel 2.4.4
On Wed, May 16, 2001 at 01:38:37PM +0200, Massimo Dal Zotto wrote: Hi, I have recently upgraded the kernel from 2.2.19 to 2.4.4 and discovered that it assigns the /dev/sd... devices in the wrong order with respect both to the behavior of kernel 2.2.19 and to the `scsihosts' boot option which I specified at the boot prompt. I have a scsi-only machine with an Adaptec 7890 and an old Symbios 53c875. The Adaptec mounts an LVD disk with the root and home partitions while the Symbios mounts two additional disks used for other purposes: ... The only way to solve my problem was to modify the makefiles and link the aic7xxx driver before the sym53c8xx, but this is a solution only for my specific case. With my patch the Adaptec is initialized first and I get a more consistent order of the scsi devices: /dev/scsi/host0/bus0/target0/lun0 /dev/sda /dev/scsi/host1/bus0/target0/lun0 /dev/sdb /dev/scsi/host1/bus0/target4/lun0 /dev/sdc I had the same problem. The fix that I use is to compile the Symbios driver as a module, and add: alias scsi_hostadapter1 sym53c8xx to my /etc/modules.conf. That way, when the kernel boots, it will only see the Adaptec driver. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
Andrzej Krzysztofowicz writes:
OK, just correct me if I get this wrong, but this code is taking the LAST 2
characters of the device name and verifying that it is cd. Which would
mean that the standard states that /dev/ginsucd would be a CD-ROM drive?
That is why I feel a name of a device handle shouldnt set how a driver
operates in this fashion... if you make a small error in your compare, you
might try to eject a Ginsu Cabbage Dicer instead of a cdrom drive... OOPS!
Sam Bingner
Alan Cox writes:
len = readlink (/proc/self/3, buffer, buflen);
if (strcmp (buffer + len - 2, cd) != 0) {
fprintf (stderr, Not a CD-ROM! Bugger off.\n);
exit (1);
And on my box cd is the cabbage dicer whoops
Actually, no, because it's guaranteed that a trailing /cd is a
CD-ROM. That's the standard.
Sure, you no longer support /dev/sdcd (eighty-second SCSI disk)...
Then you haven't looked at what devfs actually does. *All* CD-ROMs
will have a trailing pathname component of /cd. In other words, the
name of the leaf node in it's parent directory is cd.
The FAQ describes this.
Regards,
Richard
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rootfs (part 1)
On 16 May 2001, Christoph Rohland wrote: Why do you use ramfs? Most of it is duplicated in tmpfs and ramfs is a minimal _example_ fs. There was some agreement that this should stay so. Because what I need is an absolute minimum. Heck, I don't even use regular files (in the full variant of patch, that is). They might become useful, but I can live with mkdir() and mknod(). Moreover, I want it mounted very early. Right now I'm doing that after initcalls, but there's a very good reason to move the thing as early as possible. So the fewer things it uses - the better. - 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/
/dev/poll patch ?
Hi there, has anyone possibly ported the /dev/poll patch from linux-scalability project to 2.2.19 kernel ? Thank you in advance. Krzysztof - 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: wrong /dev/sd... order with multiple adapters in kernel 2.4.4
On Wed, 16 May 2001, Massimo Dal Zotto wrote: Hi, I have recently upgraded the kernel from 2.2.19 to 2.4.4 and discovered that it assigns the /dev/sd... devices in the wrong order with respect both to the behavior of kernel 2.2.19 and to the `scsihosts' boot option which I specified at the boot prompt. [SNIPPED] As a work-around, you can use modules and boot through 'initrd' where you load the modules in the order you want. When you have two SCSI disk controllers, the order at which the drives are seen will always be wrong --Murphys Law. You can control the order in which the controllers are detected and installed by using modules. Basically you cannot ever expect that multiple controllers will be detected in any particular order. They usually end up being detected in the device-order for which they exist on the PCI bus. This changes! If both of your controllers are pluggable, you can swap them on the physical bus to change the order in which they are detected. If only one is pluggable, you might try another PCI slot. It may have a number above/below the one embedded on the board. 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: LANANA: To Pending Device Number Registrants
Geert Uytterhoeven writes:
On Tue, 15 May 2001, Richard Gooch wrote:
Alan Cox writes:
len = readlink (/proc/self/3, buffer, buflen);
if (strcmp (buffer + len - 2, cd) != 0) {
fprintf (stderr, Not a CD-ROM! Bugger off.\n);
exit (1);
And on my box cd is the cabbage dicer whoops
Actually, no, because it's guaranteed that a trailing /cd is a
CD-ROM. That's the standard.
Then check for `/cd' at the end instead of `cd' :-)
Argh! What I wrote in text is what I meant to say. The code didn't
match. No wonder people seemed to be missing the point. So the line of
code I actually meant was:
if (strcmp (buffer + len - 3, /cd) != 0) {
Regards,
Richard
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
This is the problem with all sorts of ID-based naming. In this case the kernel could simply change the conflicting names a bit, and leave the cleanup to the administrator. (Who probably is around as he just inserted those disks) NO, NO, NO, NO, NO. The kernel, when asked to report on the disks physically attached to the machine, should report the location and *volume* name. It should never just mount things when there is a conflict. Make the user resolve the conflict immediately by being more specific. Partition names are sacrosanct. They should always work within the relative filesystem. If I have a disk with /, /usr and /var, I want mentions of ../var to work correctly in scripts in usr, assuming I have usr and var mounted into /. - 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] rootfs (part 1)
On 16 May 2001, Christoph Rohland wrote: cr:/speicher/src/u4ac9 $ ls -l fs/ramfs/ramfs.o -rw-r--r--1 cr users 141452 Mai 16 19:27 fs/ramfs/ramfs.o _What_? - 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/
Why O_SYNC and fsync are slow in Linux?
(Please CC your replies to me because I am not on the list.) Hi! Does anyone happen to know who is responsible for the file cache and disk management in Linux? On different systems I have measured strange differences in performance depending on whether I open a file with O_SYNC and let the operating system do the flushing of the file to disk after each write, or if I open without O_SYNC, and call fsync myself. Some observations: On Red Hat 6.2 and 7.? Intel big block writes are very slow if I open the file with O_SYNC. I call pwrite to write 1 MB chunks to the file, and I get only 1 MB/s write speed. If I open without O_SYNC and call fsync only after writing the whole 100 MB file, I get 5 MB/s. I got the same adequate speed 5 MB/s with 16 MB writes after which I called fdatasync. On a Linux-Compaq Alpha I measured the following: if I open with O_SYNC, I can flush the end of my file (it is a log file) to disk 170 times / second. If I do not open with O_SYNC, but call fsync or fdatasync after each write, I get only 50 writes/second. On the Red Hat 7.? I get 500 writes per second if I open with O_SYNC. That is too much because the disk does not rotate 500 rotations/second. Does the disk fool the operating system to believe a write has ended while it has not? On Windows NT I have not noticed such performance problems if I use non-buffered i/o to a file. I have written a database engine InnoDB under MySQL and bumped into these problems on Linux. Regards, Heikki Tuuri Innobase Oy http://www.innobase.fi - 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] rootfs (part 1)
On Wed, 16 May 2001, Linus Torvalds wrote: On Wed, 16 May 2001, Alexander Viro wrote: Linus, patch is the first chunk of rootfs stuff. I've tried to get it as small as possible - all it does is addition of absolute root on ramfs and necessary changes to mount_root/change_root/sys_pivot_root and follow_dotdot. Real root is mounted atop of the absolute one. Looks ok, but it also feels like 2.5.x stuff to me. Umm... It might be, but * it makes fixing races in fs/super.c easier and we will need that in 2.4 (or, at least, backported to 2.4 at some point) * it's backwards-compatible. * it allows to kill tons of the ugliness in rd.c in obviously correct way, for values of obviously correct equal to provably equivalent behaviour to the old code I think that it's OK for 2.4, but then I'm obviously biased (mostly by the fact that I know how much it allows to clean up without breaking any compatibility, including binary compatibility in the kernel). Up to you, indeed. Also, there's the question of whether to make ramfs just built-in, or make _tmpfs_ built in - ramfs is certainly simpler, but tmpfs does the same things and you need that one for shared mappings etc. Comments? Well, since all I actually use in the full variant of patch is sys_mknod(), sys_chdir() and sys_mkdir()... IMO tmpfs is an overkill here. Maybe we really need minimal rootfs in the kernel (no regular files) and let ramfs, tmpfs, whatever-device-fs use it as a library. 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/
locked 3c905B with 2.4.5pre2
Hello, eth0 locked after 20-30 seconds stress test, different setups: - SMP with 2 CPUs and 2 3c905B Cyclone 100baseTx cards - SMP with 1 CPU (maxcpus=1) and the same 2 cards No eth lock problems with 2.2.19 UP The scenario, a throughput test setup: flood - eth0 - forwarding - eth1 - victim The eth0 stops to respond, no oopses or problems with eth1. The system is running. Note that eth0 is used only to receive the flood. There is no much out traffic through eth0. If the forwarding is disabled there are no problems, i.e. the traffic is received and dropped. The funny messages: NETDEV WATCHDOG: eth0: transmit timed out eth0: transmit timed out, tx_status 00 status e681. diagnostics: net 0cd8 media 8880 dma 003a. eth0: Interrupt posted but not delivered -- IRQ blocked by another device? Flags; bus-master 1, dirty 123(11) current 123(11) Transmit list vs. dfe7f4c0. ... On boot: testing the IO APIC... IO APIC #2.. register #00: 0200 ...: physical APIC id: 02 register #01: 00178011 ... : max redirection entries: 0017 ... : IO APIC version: 0011 WARNING: unexpected IO-APIC, please mail to [EMAIL PROTECTED] register #02: ... : arbitration: 00 There are no IO-APIC errors! /proc/pci: Bus 0, device 0, function 0: Host bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266] (rev 1). Bus 0, device 1, function 0: PCI bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP] (rev 0). Bus 0, device 9, function 0: Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 48). IRQ 10. Bus 0, device 10, function 0: Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (#2) (rev 4 8). IRQ 11. More outputs on demand. Please, cc! Regards -- Julian Anastasov [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] rootfs (part 1)
Hi Linus, On Wed, 16 May 2001, Linus Torvalds wrote: On 16 May 2001, Christoph Rohland wrote: cr:/speicher/src/u4ac9 $ ls -l mm/shmem.o* -rw-r--r--1 cr users 154652 Mai 16 19:27 mm/shmem.o-tmpfs -rw-r--r--1 cr users 180764 Mai 16 19:24 mm/shmem.o+tmpfs cr:/speicher/src/u4ac9 $ ls -l fs/ramfs/ramfs.o -rw-r--r--1 cr users 141452 Mai 16 19:27 fs/ramfs/ramfs.o So CONFIG_TMPFS adds 26k and ramfs 140k. What the hell are you doing? Compiling with debugging or something? Yep, sorry that was uml with debugging info. The ramfs inode.o file (the only file that ramfs contains) has 376 bytes of data and 1612 bytes of code. BYTES. The whole final object file with all the relocation information is -rw-r--r-- 1 torvalds eng 5734 May 16 10:58 ramfs.o but out of that 5.5kB, only 2kB are actually linked into the kernel and are used to _run_. -rw-r--r--1 root root 8656 May 16 20:27 fs/ramfs/ramfs.o -rw-r--r--1 root root11688 May 16 20:24 mm/shmem.o-tmpfs -rw-r--r--1 root root18592 May 16 20:20 mm/shmem.o+tmpfs That's an -ac kernel, so ramfs does accounting and is a little bigger than yours. So the read/write support in tmpfs is about the same size as ramfs. Greetings Christoph - 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: wrong /dev/sd... order with multiple adapters in kernel 2.4.4
On Wed, 16 May 2001, Massimo Dal Zotto wrote: Hi, I have recently upgraded the kernel from 2.2.19 to 2.4.4 and discovered that it assigns the /dev/sd... devices in the wrong order with respect both to the behavior of kernel 2.2.19 and to the `scsihosts' boot option which I specified at the boot prompt. [SNIPPED] As a work-around, you can use modules and boot through 'initrd' where you load the modules in the order you want. I wanted to use a simpler method, a plain kernel with two static drivers which can simply be copied to /boot or to a floppy. Of course any more sophisticated method would work but I wanted a simple thing. When you have two SCSI disk controllers, the order at which the drives are seen will always be wrong --Murphys Law. You can control the order in which the controllers are detected and installed by using modules. Yes, I understand that any particular order will be wrong for some users. I'm not complaining about the current scan order. What I'm complaining about is that we do *have* a specific method of forcing the desired order (the scsihosts boot option) but this is ignored by some parts of the scsi code. I suggest that the scsihosts order is taken into account also when detecting the /dev/sd devices and not only when creating the /dev/scsi/ devices. Basically you cannot ever expect that multiple controllers will be detected in any particular order. They usually end up being detected in the device-order for which they exist on the PCI bus. This changes! This is not the case with kernel 2.4.4. They are detected in `ld' order. Changing the makefiles will change the scan order. If both of your controllers are pluggable, you can swap them on the physical bus to change the order in which they are detected. This is impossible given the density of cables and cards in the cabinet, and useless anyway given the fact that devices are detected in `ld' order. If only one is pluggable, you might try another PCI slot. It may have a number above/below the one embedded on the board. 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. -- Massimo Dal Zotto +--+ | Massimo Dal Zotto email: [EMAIL PROTECTED] | | Via Marconi, 141phone: ++39-0461534251 | | 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ | | Italy pgp: see my www home page | +--+ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
Richard Gooch wrote:
Geert Uytterhoeven writes:
On Tue, 15 May 2001, Richard Gooch wrote:
Alan Cox writes:
len = readlink (/proc/self/3, buffer, buflen);
if (strcmp (buffer + len - 2, cd) != 0) {
fprintf (stderr, Not a CD-ROM! Bugger off.\n);
exit (1);
And on my box cd is the cabbage dicer whoops
Actually, no, because it's guaranteed that a trailing /cd is a
CD-ROM. That's the standard.
Then check for `/cd' at the end instead of `cd' :-)
Argh! What I wrote in text is what I meant to say. The code didn't
match. No wonder people seemed to be missing the point. So the line of
code I actually meant was:
if (strcmp (buffer + len - 3, /cd) != 0) {
This is still a really bad idea. You don't want to tie this kind of
things to the name.
-hpa
--
[EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private!
Unix gives you enough rope to shoot yourself in the foot.
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
IP checksum broken in 2.2 .18 ip_decrease_ttl
Hi Alan,
the fast IP checksum update in ip_decrease_ttl appears
to be broken (at least on big endian machines) since 2.2.18.
Even on little endian machines IMO the overflow is incorrect
in two cases:
0xfeff goes to 0x instead of 0x
0x goes to 0x instead of 0x0100
On big endian machines, the overflow from the high byte
is never carried over correctly:
0xfeff goes to 0x instead of 0x
0xff00 goes to 0x instead of 0x0001
0xff01 goes to 0x0001 instead of 0x0002
...
0x goes to 0x00ff instead of 0x0100
The following patch reverts the ip_decrease_ttl routine
to the pre-2.2.18 level, which might be less efficient,
but should at least be correct ...
diff -urN linux-2.2.19/include/net/ip.h linux-2.2.19-s390/include/net/ip.h
--- linux-2.2.19/include/net/ip.h Sun Mar 25 18:37:40 2001
+++ linux-2.2.19-s390/include/net/ip.h Wed May 16 14:51:03 2001
@@ -171,8 +171,10 @@
int ip_decrease_ttl(struct iphdr *iph)
{
u16 check = iph-check;
-check += __constant_htons(0x0100);
-iph-check = check + ((check=0x) ? 1 : 0);
+check = ntohs(check) + 0x0100;
+if ((check 0xFF00) == 0)
+ check++;/* carry overflow */
+iph-check = htons(check);
return --iph-ttl;
}
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/
Re: [PATCH] rootfs (part 1)
Hi Alexander, On Wed, 16 May 2001, Alexander Viro wrote: Because what I need is an absolute minimum. Heck, I don't even use regular files (in the full variant of patch, that is). They might become useful, but I can live with mkdir() and mknod(). So what about adding shmem_mknod and shmem_mkdir to the core shmem.c part? They are now under CONFIG_TMPFS but are only ~20 lines of code. Greetings Christoph - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.20pre1: Problems with SMP
On Mon, May 07, 2001, Shane Wegner [EMAIL PROTECTED] wrote:
On Mon, May 07, 2001 at 11:02:50AM -0700, Johannes Erdfelt wrote:
On Mon, May 07, 2001, Shane Wegner [EMAIL PROTECTED] wrote:
That does indeed correct the problem. 2.2.20pre1 now works
as expected.
Hmm, that uses a VIA based chipset. I didn't know they did SMP yet. Does
2.4 work on this system?
The last 2.4 kernel I tried was 2.4.3 I believe and it
worked fine more or less. I haven't tried any later 2.4
kernels yet.
Could you try this patch? It applies on top of 2.2.20pre1
It also cleans up a couple of comments
JE
--- arch/i386/kernel/io_apic.c.old Wed May 16 12:48:03 2001
+++ arch/i386/kernel/io_apic.c Wed May 16 12:55:30 2001
@@ -204,6 +204,8 @@
/*
* We disable IO-APIC IRQs by setting their 'destination CPU mask' to
* zero. Trick by Ramesh Nalluri.
+ * Not anymore. This causes problems on some IO-APIC's, notably AMD 760MP's
+ * So we do it a more 2.4 kind of way now which should be safer -jerdfelt
*/
DO_ACTION( mask,0, |= 0x0001, io_apic_sync(entry-apic))/* mask = 1 */
DO_ACTION( unmask, 0, = 0xfffe, )/* mask = 0 */
@@ -646,8 +648,8 @@
entry.delivery_mode = dest_LowestPrio;
entry.dest_mode = 1;/* logical delivery */
- entry.mask = 0; /* enable IRQ */
- entry.dest.logical.logical_dest = 0xff; /* but no route */
+ entry.mask = 1; /* disable IRQ */
+ entry.dest.logical.logical_dest = 0xff;
idx = find_irq_entry(apic,pin,mp_INT);
if (idx == -1) {
-
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/
Oops in 2.2.19 when reading /proc/net/ip_masq/app
Hi I'm experiencing reproductible oopses on my stock 2.2.19 (with BadRAM patches, though I seriously doubt thet can affect described behaviour). The system is Slackware-current, kernel compiled from sources, on Pentium 120 with 32Mb RAM. The oops report is from mc but any process trying to read from /proc/net/ip_masq/app causes the oops. I suspect it may be caused by the ip_masq_netmeeting (by Alex Nicolaou, http://www.cgl.uwaterloo.ca/~anicolao/) module I inserted for a short while and then removed from the kernel, but I'm not sure as I'm not a pro kernel hacker ;-). Currently the output of lsmod looks like this: ip_masq_user2768 0 (autoclean) af_packet 6144 0 (autoclean) ip_masq_portfw 2688 1 (autoclean) ip_masq_ftp 3808 0 and ipmasqadm portfw -l has one redirection: TCP xxx.yy.zzz.www 192.168.2.2 6699 669910 10 If you want more details please CC the reply to me as I'm not subscribed to linux-kernel, though I'll try to keep up-to-dat with replies and respond appropriately. Here is what ksymoops has to say about it: May 16 20:50:50 router kernel: Unable to handle kernel paging request at virtual address c281bc93 May 16 20:50:50 router kernel: current-tss.cr3 = 008e3000, %cr3 = 008e3000 May 16 20:50:50 router kernel: *pde = 01676063 May 16 20:50:50 router kernel: Oops: May 16 20:50:50 router kernel: CPU:0 May 16 20:50:50 router kernel: EIP:0010:[vsprintf+417/764] May 16 20:50:50 router kernel: EFLAGS: 00010297 May 16 20:50:50 router kernel: eax: c281bc93 ebx: c10fc03e ecx: c281bc93 edx: fffe May 16 20:50:50 router kernel: esi: edi: c0c83f1c ebp: 0011 esp: c0c83ebc May 16 20:50:50 router kernel: ds: 0018 es: 0018 ss: 0018 May 16 20:50:50 router kernel: Process mc (pid: 6995, process nr: 63, stackpage=c0c83000) May 16 20:50:50 router kernel: Stack: 0050 0003 c178ef60 0002 0010 c0c83f28 May 16 20:50:50 router kernel:0026 c01b1e8a c10fc028 c01bde97 c0c83f0c c01b1e8a c10fc000 c01bde81 May 16 20:50:50 router kernel:c0c83f1c c0154fd1 c10fc028 c01bde82 c01bdc97 0465 c281bc93 May 16 20:50:50 router kernel: Call Trace: [sprintf+26/3824] [prio2band+2706/8667] [sprintf+26/3824] [prio2band+2684/8667] [ip_masq_app_getinfo+213/288] [prio2band+2685/8667] [prio2band+2194/8667] May 16 20:50:50 router kernel:[c281bc93] [prio2band+2651/8667] [proc_file_read+159/440] [proc_file_read+55/440] [sys_read+178/208] [error_code+53/64] [system_call+52/56] May 16 20:50:50 router kernel: Code: 80 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 8b 54 24 1c 89 c6 Trace: c281bc93 END_OF_CODE+2602acb/ Code: Before first symbol _IP: === Code: Before first symbol 0:80 38 00 cmpb $0x0,(%eax) === Code: 0003 Before first symbol 3:74 07 je 000c Before first symbol Code: 0005 Before first symbol 5:40 inc%eax Code: 0006 Before first symbol 6:4a dec%edx Code: 0007 Before first symbol 7:83 fa ff cmp$0x,%edx Code: 000a Before first symbol a:75 f4 jne0 _IP Code: 000c Before first symbol c:29 c8 sub%ecx,%eax Code: 000e Before first symbol e:8b 54 24 1c mov0x1c(%esp,1),%edx Code: 0012 Before first symbol 12:89 c6 mov%eax,%esi -- Marcin Gozdalik [EMAIL PROTECTED] Jesli chcesz odpowiedziec usun _abc If you want to reply remove _abc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
H. Peter Anvin writes:
Richard Gooch wrote:
Argh! What I wrote in text is what I meant to say. The code didn't
match. No wonder people seemed to be missing the point. So the line of
code I actually meant was:
if (strcmp (buffer + len - 3, /cd) != 0) {
This is still a really bad idea. You don't want to tie this kind of
things to the name.
Why do you think it's a bad idea?
Regards,
Richard
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: VIA/PDC/Athlon
On Wed, May 16, 2001 at 08:25:56PM +0300, Jussi Laako wrote: I tested 2.4.4-ac9 today on A7V133 machine. It booted up, but can't stand any load. It will deadlock (without oops) when the network/disk system faces any load. There is also some new bug in VIA IDE driver. It misdetects cable as 80-w when it's only 40-w and causes some CRC errors and speed dropping. Some older kernels correctly detected the cable as 40-w and used UDMA33, this one tries to use UDMA100 and fails (of course). Is there any way to force cable detection to 40-w? There were no changes lately in the VIA driver. Can you spot where the problems begun? -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
I very often had to move disks from one platform to another, and changing ID's on the was hard or impossible in some cases, and required in others. Being able to find the disk by a label is a thousand times better. Did you ever try grub?? This a gnu project, a boot-loader, with an embedded shell... You can read ext2fs and select, your kernel, your root disk, your params, etc... Yes I have tried it. Pretty cool. The only thing is what do you do if /boot sites ontop of a non ext2 partition? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
Richard Gooch wrote:
H. Peter Anvin writes:
Richard Gooch wrote:
Argh! What I wrote in text is what I meant to say. The code didn't
match. No wonder people seemed to be missing the point. So the line of
code I actually meant was:
if (strcmp (buffer + len - 3, /cd) != 0) {
This is still a really bad idea. You don't want to tie this kind of
things to the name.
Why do you think it's a bad idea?
Because you are now, once again, tying two things that are completely and
utterly unrelated: device classification and device name. It breaks
every time someone comes out with a new device which is kind of like an
old device, but not really, like CD-writers (which was kind-of-like
WORM, kind-of-like CD-ROM) and DVD (kind-of-like CD)...
-hpa
--
[EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private!
Unix gives you enough rope to shoot yourself in the foot.
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Wed, May 16, 2001 at 01:05:47PM -0700, James Simmons wrote: Did you ever try grub?? This a gnu project, a boot-loader, with an embedded shell... You can read ext2fs and select, your kernel, your root disk, your params, etc... Yes I have tried it. Pretty cool. The only thing is what do you do if /boot sites ontop of a non ext2 partition? Well if it's not ext2, fat, ffs, reiserfs or minix, too bad... On what kind of partition does your /boot site? For the machines I work with JFFS JFFS2 XFS Reiserfs ext2 - 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/
OOM deadlock with NFS on 2.4.4
Hello, we are experiencing deadlocks when running the RedHat stress test suite. The test case is basically compiling a kernel on a file system mounted via NFS from localhost (while this is obviously not particularly sensible, it should nevertheless work ...), while putting memory pressure on the system at the same time. What happens is that all tasks go to status D (or S), all CPUs go to the idle routine, and the system never recovers from this state. Appended below are excerpts from a snapshot of the deadlocked system showing the backtraces of all tasks in status D and some other info. In the test below, the machine was running on 2 CPUs and it took about three hours to deadlock; the deadlock is reached sooner when running on more CPUs. The apparent reason for the stuck system is a deadlock between the NFS server and the MM layer (page_launder etc.): As memory gets low, kswapd (and other tasks as well) decide to call page_launder to free some dirty pages. This in turn causes pages to be written to backing store. Unfortunately, the backing store happens to reside on a NFS file system, to page_launder sends an NFS request to the server and blocks, awaiting the reply. The NFS server happens to run on the same machine, and in the turn of processing the request, it needs memory. This causes page_launder to get involved again, which causes another NFS request to be sent. This goes on until the maximum amount of pending NFS requests is reached. Then, most tasks (that are not already blocked on something else) just spin around the loop in nfs_create_request, without anybody ever making any progress ... Any idea how to fix this? SETUP OF REDHAT STRESS TEST == # # This is the ctcs driver file. This file is auto-created. # set verbose 1 bg 4 NFS-COMPILE nfstest.sh bg 1024 TTCP ttcp_driver.sh localhost localhost bg 256 FIFOS_MMAP dt_driver.sh bg 64 FS fs-test-driver.sh bg 256 CRASHME crashme_driver.sh wait exit OUTPUT OF FREE == total used free sharedbuffers cached Mem:126212 125164 1048 0 1160 55528 -/+ buffers/cache: 68476 57736 Swap: 204792 8316 196476 STACK TRACES OF ALL TASKS in STATE 2 (TASK_UNINTERRUPTIBLE) === STACK TRACE FOR TASK: 0x596000 (kswapd) STACK: 0 schedule+1076 [0x1bf38] 1 schedule_timeout+178 [0x1b9f2] 2 sleep_on_timeout+134 [0x1c6f2] 3 nfs_create_request+390 [0x7c412] 4 nfs_update_request+720 [0x7d11c] 5 nfs_writepage_async+38 [0x7bdc2] 6 nfs_writepage+274 [0x7bf12] 7 page_launder+1242 [0x3edc6] 8 do_try_to_free_pages+118 [0x3fcb2] 9 kswapd+196 [0x3fdcc] 10 kernel_thread+48 [0x15574] STACK TRACE FOR TASK: 0x592000 (bdflush) STACK: 0 schedule+1076 [0x1bf38] 1 schedule_timeout+178 [0x1b9f2] 2 sleep_on_timeout+134 [0x1c6f2] 3 nfs_create_request+390 [0x7c412] 4 nfs_update_request+720 [0x7d11c] 5 nfs_writepage_async+38 [0x7bdc2] 6 nfs_writepage+274 [0x7bf12] 7 page_launder+1242 [0x3edc6] 8 bdflush+264 [0x4dfd4] 9 kernel_thread+48 [0x15574] STACK TRACE FOR TASK: 0x59 (kupdated) STACK: 0 schedule+1076 [0x1bf38] 1 schedule_timeout+178 [0x1b9f2] 2 sleep_on_timeout+134 [0x1c6f2] 3 nfs_create_request+390 [0x7c412] 4 nfs_update_request+720 [0x7d11c] 5 nfs_writepage_async+38 [0x7bdc2] 6 nfs_writepage+274 [0x7bf12] 7 filemap_fdatasync+314 [0x346fe] 8 sync_unlocked_inodes+256 [0x62f54] 9 sync_old_buffers+104 [0x4dd30] 10 kupdate+412 [0x4e1c4] 11 kernel_thread+48 [0x15574] STACK TRACE FOR TASK: 0x5274000 (klogd) STACK: 0 schedule+1076 [0x1bf38] 1 schedule_timeout+178 [0x1b9f2] 2 sleep_on_timeout+134 [0x1c6f2] 3 nfs_create_request+390 [0x7c412] 4 nfs_update_request+720 [0x7d11c] 5 nfs_writepage_async+38 [0x7bdc2] 6 nfs_writepage+274 [0x7bf12] 7 page_launder+1242 [0x3edc6] 8 do_try_to_free_pages+118 [0x3fcb2] 9 try_to_free_pages+60 [0x3fed8] 10 __alloc_pages+724 [0x40fe8] 11 __get_free_pages+60 [0x410bc] 12 read_swap_cache_async+98 [0x41b8e] 13 do_swap_page+184 [0x318b8] 14 handle_mm_fault+212 [0x31e80] 15 do_page_fault+638 [0x112ae] 16 pgm_dn [0x13720] STACK TRACE FOR TASK: 0x4cc4000 (xfs) STACK: 0 schedule+1076 [0x1bf38] 1 schedule_timeout+178 [0x1b9f2] 2 sleep_on_timeout+134 [0x1c6f2] 3 nfs_create_request+390 [0x7c412] 4 nfs_update_request+720 [0x7d11c] 5
Re: LANANA: To Pending Device Number Registrants
On Wed, May 16, 2001 at 01:05:47PM -0700, James Simmons wrote: Did you ever try grub?? This a gnu project, a boot-loader, with an embedded shell... You can read ext2fs and select, your kernel, your root disk, your params, etc... Yes I have tried it. Pretty cool. The only thing is what do you do if /boot sites ontop of a non ext2 partition? Well if it's not ext2, fat, ffs, reiserfs or minix, too bad... On what kind of partition does your /boot site? -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
Last time I checked (that was 5 minutes ago :-) )only the last two ones were supported... On Wed, May 16, 2001 at 01:16:50PM -0700, James Simmons wrote: On Wed, May 16, 2001 at 01:05:47PM -0700, James Simmons wrote: Did you ever try grub?? This a gnu project, a boot-loader, with an embedded shell... You can read ext2fs and select, your kernel, your root disk, your params, etc... Yes I have tried it. Pretty cool. The only thing is what do you do if /boot sites ontop of a non ext2 partition? Well if it's not ext2, fat, ffs, reiserfs or minix, too bad... On what kind of partition does your /boot site? For the machines I work with JFFS JFFS2 XFS Reiserfs ext2 -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Wed, 16 May 2001, Richard Gooch wrote: This is still a really bad idea. You don't want to tie this kind of things to the name. Why do you think it's a bad idea? Well, one reason names are bad is that they don't always exist. If you only have the fd (remember that unix notion of using stdin and stdout), you'd have no clue where the thing came from. So something else than the name is certainly a good idea for some of these issues. That said, I still think the real problem is rampant use of ioctl's, which are a bad idea in the first place. Magic numbers are always bad, and are a sign of bad design. Linus - 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/
Linux LVM: external CVS access
As announced 3 weeks ago, we have set up external CVS write access now. We hereby kindly invite major contributors like Andreas Dilger to join in :-) In order to set an account up, please send your address information (including postal, e-mail, phone and fax contacts) to me. We reserve the right to decide about who is gained write access. The decision will be based on just the following criteria: - submitter contributes regularly - submitter contributes major enhancements and/or bug fixes In case you are accepted, you'll get all access information to the server in return. Please add a PGP key in order to encrypt the account password for you. Thank you for supporting Linux LVM. -- Regards, Heinz-- The LVM Guy -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Heinz Mauelshagen Sistina Software Inc. Senior Consultant/Developer Am Sonnenhang 11 56242 Marienrachdorf Germany [EMAIL PROTECTED] +49 2626 141200 FAX 924446 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FW: I think I've found a serious bug in AMD Athlon page_alloc.c routines, where do I mail the developer(s) ?
I wonder if DFI has a bios or chipset patch available and whether that would help ? Maybe disabling the VIA chipset support in the kernel and running generic drivers would help ? Play with ideas see what you find out. You might strike lucky. So far nobody else has - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
Linus Torvalds writes: On Wed, 16 May 2001, Richard Gooch wrote: This is still a really bad idea. You don't want to tie this kind of things to the name. Why do you think it's a bad idea? Well, one reason names are bad is that they don't always exist. If you only have the fd (remember that unix notion of using stdin and stdout), you'd have no clue where the thing came from. So something else than the name is certainly a good idea for some of these issues. But, as I described in my original message, you use /proc/self/fd to find where the fd came from. Or are you saying that you can't rely on having /proc available? Or do you have other reasons not to like the scheme I described? One of the reasons I like it is because it requires no new kernel code. That said, I still think the real problem is rampant use of ioctl's, which are a bad idea in the first place. Magic numbers are always bad, and are a sign of bad design. No argument from me. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ACP Modem (Mwave)
Subject says it all... The patch is the driver portion for the Mwave applied against the 2.4.4 kernel proper.. It was a little big to send directly to the list.. So... You'll be able to pick it up at http://www.ibm.com/linux/ltc/ shortly.. Until it goes up there, it will be available at http://www.haywired.net/MWAVE/... Please throw any comments, questions, suggestions, hard objects this way... Cheers...Paul... --- Paul B Schroeder [EMAIL PROTECTED] Software Engineer, Linux Technology Center IBM Corporation, Austin, TX - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
I don't mean to suggest that ioctls be used to deduce device types (except in the case of overlapping ioctl numbers, which shouldn't be all *that* common (I hope)). I mean to suggest that the question What device type are you? usually shouldn't even be asked! But people need to ask it. Sometimes it really matters. It doesnt have to be in your face as /dev/hda1 versus /dev/sda1 is but it has to be possible - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel2.2.x to kernel2.4.x
I tried porting a network driver from kernel2.2.x to 2.4. When i tried loading the driver, it shows the unresolved symbols for copy_to_user_ret if(copy_to_user(...)) return -EFAULT outs Has not gone away, your includes are wrong __bad_udelay You are using too large a udelay use mdelay - 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] device_init
Linus, please apply the patch below (device_init as initcall).
BTW, if -pre3 didn't break the init sequence I would be very surprised -
chr_dev_init() is moved _way_ past the other device initialization stuff.
Al
diff -urN S5-pre3/drivers/block/genhd.c S5-pre3-device_init/drivers/block/genhd.c
--- S5-pre3/drivers/block/genhd.c Wed May 16 16:26:35 2001
+++ S5-pre3-device_init/drivers/block/genhd.c Wed May 16 16:40:11 2001
@@ -29,7 +29,7 @@
extern int cpqarray_init(void);
extern void ieee1394_init(void);
-void __init device_init(void)
+int __init device_init(void)
{
blk_dev_init();
sti();
@@ -58,4 +58,7 @@
#ifdef CONFIG_VT
console_map_init();
#endif
+ return 0;
}
+
+__initcall(device_init);
diff -urN S5-pre3/fs/partitions/check.c S5-pre3-device_init/fs/partitions/check.c
--- S5-pre3/fs/partitions/check.c Thu Feb 22 06:45:26 2001
+++ S5-pre3-device_init/fs/partitions/check.c Wed May 16 16:40:11 2001
@@ -33,10 +33,7 @@
#include ibm.h
#include ultrix.h
-extern void device_init(void);
extern int *blk_size[];
-extern void rd_load(void);
-extern void initrd_load(void);
struct gendisk *gendisk_head;
int warn_no_part = 1; /*This is ugly: should make genhd removable media aware*/
@@ -438,19 +435,3 @@
blk_size[dev-major] = dev-sizes;
}
}
-
-int __init partition_setup(void)
-{
- device_init();
-
-#ifdef CONFIG_BLK_DEV_RAM
-#ifdef CONFIG_BLK_DEV_INITRD
- if (initrd_start mount_initrd) initrd_load();
- else
-#endif
- rd_load();
-#endif
- return 0;
-}
-
-__initcall(partition_setup);
diff -urN S5-pre3/init/main.c S5-pre3-device_init/init/main.c
--- S5-pre3/init/main.c Wed May 16 16:26:46 2001
+++ S5-pre3-device_init/init/main.c Wed May 16 16:40:36 2001
@@ -638,9 +638,6 @@
*/
static void __init do_basic_setup(void)
{
-#ifdef CONFIG_BLK_DEV_INITRD
- int real_root_mountflags;
-#endif
/*
* Tell the world that we're going to be the grim
@@ -707,13 +704,6 @@
/* Networking initialization needs a process context */
sock_init();
-#ifdef CONFIG_BLK_DEV_INITRD
- real_root_dev = ROOT_DEV;
- real_root_mountflags = root_mountflags;
- if (initrd_start mount_initrd) root_mountflags = ~MS_RDONLY;
- else mount_initrd =0;
-#endif
-
start_context_thread();
do_initcalls();
@@ -724,6 +714,33 @@
#ifdef CONFIG_PCMCIA
init_pcmcia_ds(); /* Do this last */
#endif
+}
+
+extern void rd_load(void);
+extern void initrd_load(void);
+
+/*
+ * Prepare the namespace - decide what/where to mount, load ramdisks, etc.
+ */
+static void prepare_namespace(void)
+{
+#ifdef CONFIG_BLK_DEV_INITRD
+ int real_root_mountflags = root_mountflags;
+ if (!initrd_start)
+ mount_initrd = 0;
+ if (mount_initrd)
+ root_mountflags = ~MS_RDONLY;
+ real_root_dev = ROOT_DEV;
+#endif
+
+#ifdef CONFIG_BLK_DEV_RAM
+#ifdef CONFIG_BLK_DEV_INITRD
+ if (mount_initrd)
+ initrd_load();
+ else
+#endif
+ rd_load();
+#endif
/* Mount the root filesystem.. */
mount_root();
@@ -755,6 +772,8 @@
{
lock_kernel();
do_basic_setup();
+
+ prepare_namespace();
/*
* Ok, we have completed the initial bootup, and
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
H. Peter Anvin writes:
Richard Gooch wrote:
H. Peter Anvin writes:
Richard Gooch wrote:
Argh! What I wrote in text is what I meant to say. The code didn't
match. No wonder people seemed to be missing the point. So the line of
code I actually meant was:
if (strcmp (buffer + len - 3, /cd) != 0) {
This is still a really bad idea. You don't want to tie this kind of
things to the name.
Why do you think it's a bad idea?
Because you are now, once again, tying two things that are
completely and utterly unrelated: device classification and device
name. It breaks every time someone comes out with a new device
which is kind of like an old device, but not really, like
CD-writers (which was kind-of-like WORM, kind-of-like CD-ROM) and
DVD (kind-of-like CD)...
But all devices which export a CD-ROM interface will do so. So the
device node that is associated with the CD-ROM driver will export
CD-ROM semantics, and the trailing name will be /cd.
Other interfaces a device exports, such as a CD-RW, appear as a
different device node (generic for SCSI, because we have no CD-RW
classification at this point).
My scheme works already, and works reliably. Nothing had to be done to
support the CD-ROM interface to CD-RW and DVD devices.
Regards,
Richard
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
((struct pci_dev*)dev)-resource[...].start
Can someone please confirm if my assumptions below are correct: 1) Unless someone specifically tampered with my driver's device since the OS bootup, the mapping of the PCI base address registers to virtual memory will remain the same (just as seen in /proc/pci, and as reflected in subj)? If not, is there a way to freeze it for the time I want to access it? 2) (Basically, the question is Do I understand Documentation/IO-mapping.txt right?) PCI memory, whenever IO type or memory type, can not be dereferenced but should be accessed with readb() etc. On i386, PCI mem (memory type) can be accessed by direct pointer access, but this is not portable. Kind regards, Vassilii - 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/
No Subject
Please CC replies as I'm not subscribed.
I seem to be having some problems with sound ioctl's.
I've attached a short c file that opens /dev/dsp, prints the fd, tries
to issue SNDCTL_DSP_NONBLOCK ioctl, then does the same with /dev/audio.
Both calls to ioctl for NONBLOCK yield Invalid Invalid argument.
I've searched the kernel source under drivers/sound/ to see if/where
this ioctl is defined.
grep -rl SNDCTL_DSP_NONBLOCK drivers/sound/*
drivers/sound/audio.c
drivers/sound/cmpci.c
drivers/sound/cs4281/cs4281m.c
drivers/sound/cs46xx.c
drivers/sound/emu10k1/audio.c
drivers/sound/es1370.c
drivers/sound/es1371.c
drivers/sound/esssolo1.c
drivers/sound/i810_audio.c
drivers/sound/maestro.c
drivers/sound/maestro3.c
drivers/sound/msnd_pinnacle.c
drivers/sound/sonicvibes.c
drivers/sound/trident.c
drivers/sound/vwsnd.c
drivers/sound/ymfpci.c
Now I'm using a via chipset embedded sound.
lsmod
via82cxxx_audio16496 0 (autoclean)
soundcore 3472 2 (autoclean) [via82cxxx_audio]
ac97_codec 8352 0 (autoclean) [via82cxxx_audio]
So none of the files that use SNDCTL_DSP_NONBLOCK were compiled for my
kernel. I came up with a question and 2 possible solutions.
Question:
Are all ioctl's valid for all devices within a major block?
Solutions:
1. Turn on CONFIG_SOUND_OSS so sound.o is produced, however the
Configure.help says, ...Say Y or M here (the module will be called
sound.o) if you haven't found a driver for your sound card above, then
pick your driver from the list below.
2. Determine a way to tell which ioctl's a particular driver supports.
Any ideas here?
--
Gordon Sadler
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include sys/ioctl.h
#include unistd.h
#include stdio.h
#include linux/soundcard.h
int main()
{
int fd, fd1, ver;
if((fd=open(/dev/dsp,O_WRONLY))0)
perror(open );
printf ( %d is fd...\n,fd);
if (ioctl(fd, OSS_GETVERSION, ver)0)
perror(ioctl );
printf ( %x is version...\n,ver);
if (ioctl(fd, SNDCTL_DSP_NONBLOCK, NULL)0)
perror(ioctl );
close(fd);
if((fd1=open(/dev/audio,O_WRONLY))0)
perror(open );
printf ( %d is fd1...\n,fd);
if (ioctl(fd1, SNDCTL_DSP_NONBLOCK, NULL)0)
perror(ioctl );
close(fd1);
return 0;
}
Re: LANANA: To Pending Device Number Registrants
Richard Gooch wrote: Because you are now, once again, tying two things that are completely and utterly unrelated: device classification and device name. It breaks every time someone comes out with a new device which is kind of like an old device, but not really, like CD-writers (which was kind-of-like WORM, kind-of-like CD-ROM) and DVD (kind-of-like CD)... But all devices which export a CD-ROM interface will do so. So the device node that is associated with the CD-ROM driver will export CD-ROM semantics, and the trailing name will be /cd. Other interfaces a device exports, such as a CD-RW, appear as a different device node (generic for SCSI, because we have no CD-RW classification at this point). My scheme works already, and works reliably. Nothing had to be done to support the CD-ROM interface to CD-RW and DVD devices. It's still completely braindamaged: (a) these interfaces aren't disjoint. They refer to the same device, and will interfere with each other; (b) it is highly undesirable to tie the naming to the interfaces in this way. It further restricts the namespaces you can export, for one thing. -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! Unix gives you enough rope to shoot yourself in the foot. http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ((struct pci_dev*)dev)-resource[...].start
Khachaturov, Vassilii wrote:
Can someone please confirm if my assumptions below are correct:
1) Unless someone specifically tampered with my driver's device since the OS
bootup, the mapping of the PCI base address registers to virtual memory will
remain the same (just as seen in /proc/pci, and as reflected in subj)? If
not, is there a way to freeze it for the time I want to access it?
This is not a safe assumption, because the OS may reprogram the PCI BARs
at certain times. The rule is: ALWAYS read from dev-resource[] unless
you are a bus driver (PCI bridges, for example, need to assign
resources).
Further, access to PCI BARs -and- dev-resource[] in a driver is wrong
until you have called pci_enable_device. Resource and IRQ assignment
potentially occurs at pci_enable_device time, so BAR is [potentially]
undefined before then.
Finally, make sure to use pci_resource_{start,end,len,flags} macros to
make your core more portable and future-proof.
2) (Basically, the question is Do I understand Documentation/IO-mapping.txt
right?)
PCI memory, whenever IO type or memory type, can not be dereferenced but
should be accessed with readb() etc. On i386, PCI mem (memory type) can be
accessed by direct pointer access, but this is not portable.
We will yell at you mightily if you directly access PCI mem with a
pointer. As you say it only works on i386 -- but IIRC since ioremap is
required, we are perfectly free to change or modify that assumption.
For example ioremap might [have to] care about whether or not a pci mem
region is prefetchable.
--
Jeff Garzik | Game called on account of naked chick
Building 1024|
MandrakeSoft |
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
Michael Meissner writes: On Tue, May 15, 2001 at 01:18:09PM -0700, Linus Torvalds wrote: This is what we have now. Network devices are called eth0..N, and nobody is complaining about the fact that the numbering is basically random. It is _repeatable_ as long as you don't change your hardware setup, and the numbering has effectively _nothing_ to do with location. Well yes and no. The numbers are currently repeatable for a given kernel, but I know I and others were bitten by the 2.2. to 2.4 transition, where the kernel used a different algorithm for the order in which it detected scsi and network adapters (ie, in my machine with 3 scsi adapters, Linux 2.2 always picked the Adaptec scsi adapter builtin into my motherboard as the first adapter, but 2.4 decided to pick my TekRam 390F adapter). With a proper user-space solution for device naming, you wouldn't care what order the kernel enumerated devices in. You want the kernel to list all of the devices (in any order), and then user-space is in charge of creating (or maintaining) a semi-permanent ID to device mapping regardless of what the major/minor number or physical device location is. As lots of people have been saying, you need to know which physical slot to plut the wire connecting eth0, eth1, etc. into. Similarly for serial ports, if I have 3 or 4 (or 127 :-) USB serial devices, I really don't want to have to change my cabling each time I boot or change OSes (since I doubt my UPS will be happy if I give it the commands destined for the X10 controller or my remote boards). If you keep a static database (in userspace) of device name - physical device mappings, then you are safe as long as either: a) There is some way to identify a device which has moved (H/W serial number, LVM/fs UUID/label, unique make/model, etc). b) You can get some physical location information about the device (i.e. I/O port address, bus/slot information, etc). Linux currently always assumes that (b) implies the order of enumerating devices is fixed, even when it isn't always true (hence problems with SCSI addressing, ethernet cards, etc). We _should_ be using (a) as much as it is possible. If both (a) and (b) are not true (e.g. two USB mice (no serial number) and you change your USB layout) then there isn't much that software can do without user intervention. At least if there is a simple mapping table maintained in user space(*), it is easy to switch the identities of devices to whatever they want with little effort, rather than having to re-do all of their other config files. Note that despite the presence of (b), we should NOT use this information as part of the device name, since we want to be able to keep the same device name (possibly with a _small_ bit of user intervention) even if the device moves around. Cheers, Andreas (*) Something like a simple lookup table with name=value pairs (very e.g.): ide-serial:a1e2a40a5e03=disk0 scsi-serial:xj23as88d=disk1 mdraid-uuid:3b02f06c-2c33-5905-c247-1f806535505c=disk7 isa-ioport:03f8=ttyS0 isa-ioport:02f8=ttyS1 isa-ioport:02e8=ttyS3 -- 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/
clock timer configuration lost on Serverworks chipset
I'm getting messages saying clock timer configuration lost - probably a VIA686a from 2.2.19 running on a board using the Serverworks HE chipset. Reading the list archives it sounds like this problem has previously been attributed to a possible bug in the VIA chipset. According to RedHat's bugzilla database, others have seen it on Serverworks chipsets, too. And it sounds like using noapic sometimes makes it go away, which doesn't make much sense to me. How well has the problem been nailed down? Could it be that it just showed up first on VIA and the real cause (and fix) remains to be discovered? Or does Serverworks somehow have an identical bug in their chipset? jcastle - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Wed, May 16, 2001 at 02:36:44PM -0700, H. Peter Anvin wrote: But all devices which export a CD-ROM interface will do so. So the device node that is associated with the CD-ROM driver will export CD-ROM semantics, and the trailing name will be /cd. Other interfaces a device exports, such as a CD-RW, appear as a different device node (generic for SCSI, because we have no CD-RW classification at this point). My scheme works already, and works reliably. Nothing had to be done to support the CD-ROM interface to CD-RW and DVD devices. It's still completely braindamaged: (a) these interfaces aren't disjoint. They refer to the same device, and will interfere with each other; (b) it is highly undesirable to tie the naming to the interfaces in this way. It further restricts the namespaces you can export, for one thing. We do this already with ide-scsi. A device is visible as /dev/hda and /dev/sda at the same time. Or think IDE-CDRW: /dev/hda, /dev/sr0 and /dev/sg0. All at the same time. It is perfectly normal to export different interfaces for the same device. This is basically, what subfunctions on PCI do: Same device with different interfaces. Just that we do it through a driver with ide and through the hardware with a multi function PCI card. Applications don't care about devices. They care about entities that have capabilities and programming interfaces. What they _really_ are and if this is only emulated is not important. Sorry, I don't see your point here :-( Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
Ingo Oeser wrote: We do this already with ide-scsi. A device is visible as /dev/hda and /dev/sda at the same time. Or think IDE-CDRW: /dev/hda, /dev/sr0 and /dev/sg0. All at the same time. ... and if you don't know about this funny aliasing, you get screwed. This is BAD DESIGN, once again. It is perfectly normal to export different interfaces for the same device. This is basically, what subfunctions on PCI do: Same device with different interfaces. Just that we do it through a driver with ide and through the hardware with a multi function PCI card. Applications don't care about devices. They care about entities that have capabilities and programming interfaces. What they _really_ are and if this is only emulated is not important. Sorry, I don't see your point here :-( That seems to be a common theme with you. -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! Unix gives you enough rope to shoot yourself in the foot. http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: ((struct pci_dev*)dev)-resource[...].start
Jeff,
Many thanks for the clarifications.
From: Jeff Garzik
Khachaturov, Vassilii wrote:
[snip]
bootup, the mapping of the PCI base address registers to
virtual memory will
remain the same (just as seen in /proc/pci, and as
reflected in subj)? If
not, is there a way to freeze it for the time I want to access it?
This is not a safe assumption, because the OS may reprogram
the PCI BARs
at certain times. The rule is: ALWAYS read from
dev-resource[] unless
you are a bus driver (PCI bridges, for example, need to assign
resources).
[snip]
I am not a bus driver, and I do call pci_enable_device once my device gets
probed and recognized by my driver. I always read from dev-resource[].
But what are the certain times you've mentioned? What is the scope
within which I know the BARs didn't change?
Finally, make sure to use pci_resource_{start,end,len,flags} macros to
make your core more portable and future-proof.
I didn't use the macros - now I do, thanks for the tip!
2) (Basically, the question is Do I understand
Documentation/IO-mapping.txt
right?)
PCI memory, whenever IO type or memory type, can not be
dereferenced but
should be accessed with readb() etc. On i386, PCI mem
(memory type) can be
accessed by direct pointer access, but this is not portable.
We will yell at you mightily if you directly access PCI mem with a
pointer. As you say it only works on i386 -- but IIRC since
Right now I am porting a driver to Linux which has so much i386 things in it
(esp. byte order stuff). So far I haven't spoilt it with PCI i386 hacks
though...
ioremap is
required, we are perfectly free to change or modify that assumption.
For example ioremap might [have to] care about whether or not
a pci mem
region is prefetchable.
A really silly q. (I don't quite understand the Linux internals yet):
Is ioremap() needed (in general vs. i386) for memory type PCI memory too,
or only for IO type?
(In case the default size of the region associated with a BAR is fine with
me?)
Thanks,
Vassilii
-
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] rootfs (part 1)
Followup to: [EMAIL PROTECTED] By author:Alexander Viro [EMAIL PROTECTED] In newsgroup: linux.dev.kernel Well, since all I actually use in the full variant of patch is sys_mknod(), sys_chdir() and sys_mkdir()... IMO tmpfs is an overkill here. Maybe we really need minimal rootfs in the kernel (no regular files) and let ramfs, tmpfs, whatever-device-fs use it as a library. One thing that I thought was really spiffy was someone who had done patches to populate a ramfs from a tarball loaded via the initrd bootloader protocol... call it initial ramfs. It allowed a whole lot of cleanup -- the initrd isn't magic anymore (instead use pivot_root), and it gets rid of the rd stuff. At the same time it does allow the full flexibility of a fullblown filesystem that can be populated with arbitrary contents. -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! Unix gives you enough rope to shoot yourself in the foot. http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Wed, May 16 2001, H. Peter Anvin wrote: Ingo Oeser wrote: We do this already with ide-scsi. A device is visible as /dev/hda and /dev/sda at the same time. Or think IDE-CDRW: /dev/hda, /dev/sr0 and /dev/sg0. All at the same time. ... and if you don't know about this funny aliasing, you get screwed. This is BAD DESIGN, once again. And he's wrong too, we don't do this all the time. If /dev/hda is ide-cd controlled, then it can't be accessed through /dev/sr0 -- and vice versa. sg vs sr is different, one is a char the other a block device. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
cmpci sound chip lockup
The attatched file is the format for reporting bugs. 1) While playing mp3's on mpg123 it'll lock up for 3/4 seconds, and XMMS just stops all together 2) May 16 05:46:10 virii kernel: cmpci: dma timed out?? May 16 06:05:43 virii kernel: cmpci: write: chip lockup? dmasz 65536 fragsz 1024 count 65536 hwptr 40576 swptr 40576 3) cmpci.o soundcore.o happens when compiled into kernel or as modules 4) Linux version 2.2.19 (root@virii) (gcc version 2.95.3 20010315 (release)) #2 SMP Sat Apr 21 13:51:28 CDT 2001 note [this happend with all the 2.4.* as well.] 6) just while playing music with mpg123 or xmms, or any other mp3 player. 7) using Slackware-current 8) Gnu C 2.95.3 Gnu make 3.79.1 binutils 2.10.1.0.4 util-linux 2.11b modutils 2.4.6 e2fsprogs 1.19 reiserfsprogs 3.x.0j pcmcia-cs 3.1.25 PPP2.4.1 Linux C Library2.2.2 Dynamic linker (ldd) 2.2.2 Procps 2.0.7 Net-tools 1.59 Kbd1.04 Sh-utils 2.0 Modules Loaded bsd_comp ppp slhc 9) processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 8 model name : AMD-K6(tm) 3D processor stepping: 12 cpu MHz : 522.818 cache size : 64 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mmx 3dnow bogomips: 1042.02 10) bsd_comp4080 1 ppp21680 2 [bsd_comp] slhc4496 1 [ppp] 11) Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: E-IDEModel: CD-ROM 50X Rev: 33 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 01 Lun: 00 Vendor: IDE-CD Model: R/RW 4x4x24 Rev: 1.04 Type: CD-ROM ANSI SCSI revision: 02 12) root@virii:~# lspci 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 530 Host (rev 03) 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 b3) 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:0c.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10) 00:0c.1 Communication controller: C-Media Electronics Inc CM8738 (rev 10) 01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 6306 3D-AGP (rev a3)
CMPXCHG
Four adapters need to produce data to a descriptor queue which is consumed by a user process. A lock mechanism was implemented to sync the adapters. However, this causes a performance hit. Is it possible to use CMPXCHG on Intel's i-386 to avoid the locking? Where can I find some doc and some sample code? Thx -Scott - 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: cmpci sound chip lockup
On Wed, 16 May 2001, virii wrote: The attatched file is the format for reporting bugs. Too bad my mailreader doesn't quote that thing .. oh well, lets just replace your bugreport with mine ;) I'm seeing a similar thing on 2.4.4-pre[23], but in a far less serious way. Using xmms the music stops after anything between a few seconds and a minute, I suspect a race condition somewhere. Using mpg123 everything works fine... regards, 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: ((struct pci_dev*)dev)-resource[...].start
At 5:37 PM -0400 2001-05-16, Jeff Garzik wrote: This is not a safe assumption, because the OS may reprogram the PCI BARs at certain times. The rule is: ALWAYS read from dev-resource[] unless you are a bus driver (PCI bridges, for example, need to assign resources). Would you please elaborate? If I understand what you're saying, you can't rely on the pointer returned by ioremap() because the OS might reprogram the relevant BAR out from under you. So one would need to know: when does a driver have to re-ioremap() due to the BAR having been (potentially) changed? I'd expect the answer to be: for all practical purposes never. -- /Jonathan Lundell. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
H. Peter Anvin writes: Ingo Oeser wrote: We do this already with ide-scsi. A device is visible as /dev/hda and /dev/sda at the same time. Or think IDE-CDRW: /dev/hda, /dev/sr0 and /dev/sg0. All at the same time. ... and if you don't know about this funny aliasing, you get screwed. This is BAD DESIGN, once again. We have this aliasing anyway. sg and sr are just one example. If you care about conflicts, then make sure the drivers lock each other out. It's got nothing to do with the mechanism to find out whether something can behave like a CD-ROM or not. Sorry, I don't see your point here :-( That seems to be a common theme with you. C'mon, Peter. No need for that. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rootfs (part 1)
On 16 May 2001, H. Peter Anvin wrote: Followup to: [EMAIL PROTECTED] By author:Alexander Viro [EMAIL PROTECTED] In newsgroup: linux.dev.kernel Well, since all I actually use in the full variant of patch is sys_mknod(), sys_chdir() and sys_mkdir()... IMO tmpfs is an overkill here. Maybe we really need minimal rootfs in the kernel (no regular files) and let ramfs, tmpfs, whatever-device-fs use it as a library. One thing that I thought was really spiffy was someone who had done patches to populate a ramfs from a tarball loaded via the initrd bootloader protocol... call it initial ramfs. It allowed a whole lot of cleanup -- the initrd isn't magic anymore (instead use pivot_root), and it gets rid of the rd stuff. At the same time it does allow the full flexibility of a fullblown filesystem that can be populated with arbitrary contents. In full variant of patch I don't _have_ mount_root(9). It's done by mount(2). Period. Initrd or not. Notice that rootfs stays absolute root forever - it's much more convenient for fs/super.c, since you can get rid of many kludges that way. So I'm not too happy about populating rootfs with tons of files. BTW, loading initrd is done by open(2), read(2) and write(2) - none of this fake struct file business anymore. So late-boot stuff (mounting root, unpacking initrd, mounting devfs if asked to, loading initrd from floppies, moving initrd around - the whole whorehouse) is actually done by sane, normal system calls. And it's very easy to expand - I refused to apply any fancy patches simply because I wanted 100% compatibility with all existing boot setups, no matter how silly they are. If behaviour is absent in Linus' tree - sorry. However, playing with that stuff becomes much easier - essentially it's a userland code. You have an empty, writable fs, your root and cwd are on it, you can do any system calls you want. So if you want this untar-into-ramfs - well, more power to you. I'd recommend to use a separate instance of ramfs for that, though, so that you could easily get rid of it afterwards. Again, at that point you have normal userland environment, so doing whatever you want to do doesn't require any kernel-specific stuff. Write as if you were adding your code to the beginning of /sbin/init. - 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/
oops in 2.4.4-ac9 (mm/slab.c)
Hello people,
I triggered an invalid operand oops in linux-2.4.4-ac9 today, and could
trace it back to the line mm/slab.c:1244. I did nothing really special
when this happened, and I was not able to log in onto any console or
terminal afterwards (probably because tty_open failed very miserably
on the way?)
The final BUG() is found inside:
static inline void * kmem_cache_alloc_one_tail (kmem_cache_t *cachep,
slab_t *slabp)
{
[...]
#if DEBUG
if (cachep-flags SLAB_POISON)
if (kmem_check_poison_obj(cachep, objp))
BUG();
^^ This one is triggered
if (cachep-flags SLAB_RED_ZONE) {
/* Set alloc red-zone, and check old one. */
[...]
#endif
[...]
}
So CONFIG_DEBUG_SLAB (which I have enabled, out of curiosity and to help you all)
might have found a bug here.
ksymoops output is found below.
Greetings and happy hacking,
Andreas
---snip---
ksymoops 2.4.0 on i686 2.4.4-ac9. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.4-ac9/ (default)
-m /boot/System.map-2.4.4-ac9 (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.
Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(bm_cast_buffer) not found
in System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(bm_copy_to_buffer) not
found in System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(bm_evaluate_object) not
found in System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol
__VERSIONED_SYMBOL(bm_evaluate_reference_list) not found in System.map. Ignoring
ksyms_base entry
Warning (compare_maps): ksyms_base symbol
__VERSIONED_SYMBOL(bm_evaluate_simple_integer) not found in System.map. Ignoring
ksyms_base entry
Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(bm_extract_package_data)
not found in System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(bm_get_device_context)
not found in System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(bm_get_device_info) not
found in System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol
__VERSIONED_SYMBOL(bm_get_device_power_state) not found in System.map. Ignoring
ksyms_base entry
Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(bm_get_device_status) not
found in System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(bm_get_node) not found in
System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(bm_osl_generate_event)
not found in System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(bm_proc_root) not found
in System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(bm_register_driver) not
found in System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(bm_request) not found in
System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(bm_search) not found in
System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol
__VERSIONED_SYMBOL(bm_set_device_power_state) not found in System.map. Ignoring
ksyms_base entry
Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(bm_unregister_driver) not
found in System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_fadt_R__ver_acpi_fadt not found in
System.map. Ignoring ksyms_base entry
Warning (compare_maps): mismatch on symbol partition_name , ksyms_base says c01f2b40,
System.map says c01485d0. Ignoring ksyms_base entry
invalid operand:
CPU:0
EIP:0010:[c012621e]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010012
eax: dea55fff ebx: c40fc768 ecx: 0001 edx: 0001
esi: dea55000 edi: dea559aa ebp: 00012800 esp: cc0d1e68
ds: 0018 es: 0018 ss: 0018
Process blogd (pid: 4143, stackpage=cc0d1000)
Stack: 8000 c03219c0 c03219c0 1000 dea559aa 0246 c017ad0d
0c3c 0007 c03219c0 c017b92c c03219c0 c03219c0
cc0d df8ee658 cc0d
Call Trace: [c017ad0d] [c017b92c] [c017c34b] [c012e70f] [c0137717]
[c012e892]
Re: ((struct pci_dev*)dev)-resource[...].start
Jonathan Lundell wrote: At 5:37 PM -0400 2001-05-16, Jeff Garzik wrote: This is not a safe assumption, because the OS may reprogram the PCI BARs at certain times. The rule is: ALWAYS read from dev-resource[] unless you are a bus driver (PCI bridges, for example, need to assign resources). Would you please elaborate? If I understand what you're saying, you can't rely on the pointer returned by ioremap() because the OS might reprogram the relevant BAR out from under you. So one would need to know: when does a driver have to re-ioremap() due to the BAR having been (potentially) changed? I'd expect the answer to be: for all practical purposes never. no-no-no. I DON'T mean that OS will reprogram the BARs underneath you. Only that it is the responsibility of the OS to program the BARs, and that you should be getting the BAR info out of dev-resource[]. Note only does this make the code much cleaner, but this gives us a lot more flexibility about when and how we program the PCI bus. The PCI driver only needs to know the location and size of the region it needs to access. If the OS, in the future, has to support some weird IOMMU or PCI mapping capabilities, we don't have to go through and change all the drivers which are suddenly broken by this new hardware... we just change it in one canonical place: the PCI core. (at this point the lecture turns into why APIs exist and should be used, and it gets more boring from there...) -- Jeff Garzik | Game called on account of naked chick Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ymfpci.h add PCIR_DSXPWRCTRL1 PCIR_DSXPWRCTRL2
Woopsthis is for 2.4.5-pre2 I guessed - its ok by default in -ac because I do a test build with everything I can build built as modules - 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] rootfs (part 1)
Alexander Viro wrote: In full variant of patch I don't _have_ mount_root(9). It's done by mount(2). Period. Initrd or not. Notice that rootfs stays absolute root forever - it's much more convenient for fs/super.c, since you can get rid of many kludges that way. So I'm not too happy about populating rootfs with tons of files. BTW, loading initrd is done by open(2), read(2) and write(2) - none of this fake struct file business anymore. OK, I see what you're doing now. However, I'm confused what you mean with rootfs stays absolute root forever -- does that mean that you mount the new root on top of /, and so the rootfs remains in the system never to be reclaimed, as opposed to pivot_root-ing it? -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! Unix gives you enough rope to shoot yourself in the foot. http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IRQ usage for PCI devices, Kernel 2.4.4
May 13 14:24:41 sunny kernel: PCI: Found IRQ 10 for device 00:0e.0 May 13 14:24:41 sunny kernel: PCI: The same IRQ used for device 00:0a.0 0e is my PCI sound card, and 0a is my PCI ethernet card. The messages apppear in the following environment: I send from another linux machine (per ssh) a command wich plays some sound on my sound card, therefore the eth0 event and the sound event occur at almost the same time. Question: Can I ignore these messages, or is there any buggy behaviour? This is debugging messages - you can ignore them. PCI supports IRQ sharing - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
Richard Gooch wrote: H. Peter Anvin writes: Ingo Oeser wrote: We do this already with ide-scsi. A device is visible as /dev/hda and /dev/sda at the same time. Or think IDE-CDRW: /dev/hda, /dev/sr0 and /dev/sg0. All at the same time. ... and if you don't know about this funny aliasing, you get screwed. This is BAD DESIGN, once again. We have this aliasing anyway. sg and sr are just one example. If you care about conflicts, then make sure the drivers lock each other out. It's got nothing to do with the mechanism to find out whether something can behave like a CD-ROM or not. No fscking way. What you're saying well, my design is broken, so break your driver even further. You're suggesting prohibiting legal (and useful) operations because you're advocating an idiotic design to identify devices? Give me a break. -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! Unix gives you enough rope to shoot yourself in the foot. http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
Are FireWire (and USB) disks always detected in the same order? Or does it behave like ADB, where you never know which mouse/keyboard is which mouse/keyboard? USB disks are required (haha etc) to have serial numbers. Firewire similarly has unique disk identifiers. - 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] rootfs (part 1)
On Wed, 16 May 2001, H. Peter Anvin wrote: Alexander Viro wrote: In full variant of patch I don't _have_ mount_root(9). It's done by mount(2). Period. Initrd or not. Notice that rootfs stays absolute root forever - it's much more convenient for fs/super.c, since you can get rid of many kludges that way. So I'm not too happy about populating rootfs with tons of files. BTW, loading initrd is done by open(2), read(2) and write(2) - none of this fake struct file business anymore. OK, I see what you're doing now. However, I'm confused what you mean with rootfs stays absolute root forever -- does that mean that you mount the new root on top of /, and so the rootfs remains in the system never to be reclaimed, as opposed to pivot_root-ing it? Yes. Pivot_root works, all right, but it rotates (your process' root, old, new). So it works in chroot correctly now. And since we chroot out of the absolute root when we mount initrd (or final root, for that matter) any setup that used pivot_root keeps working as it did. As for never to be reclaimed... Let's see: 1 struct super_block 1 struct vfsmount couple of struct dentry couple of struct inode (for values of couple from 1 to 4; we can reduce it to 1 but I didn't bother with that; all it takes is a couple of calls of sys_rmdir()/sys_unlink()). Compared to the amount of space we free in .code of fs/super.c it's noise. - 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: wd7000 missing release_region
One else case in wd7000.c did not have a release_region(). Most of these are fixed in -ac and have been for a while. Im not sure if this one is but do double check the -ac patches for these. I've yet to have Linus bandwidth to feed them all on - 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: RH 7.1 on IBM xSeries 240
hm, page 0009f000 reserved twice. hm, page 000a reserved twice. WARNING: MP table in the EBDA can be UNSAFE These are ok... ENABLING IO-APIC IRQs ...changing IO-APIC physical APIC ID to 14 ... ok. BIOS bug, IO-APIC#1 ID is 15 in the MPC table!... ... fixing up to 15. (tell your hw vendor) Your BIOS tables seemed wrong.. mtrr: your CPUs had inconsistent fixed MTRR settings mtrr: probably your BIOS does not setup all CPUs And your BIOS fails to set up the MTRR's properly. These are real BIOS mistakes. They are ones Linux however took corrective action on. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
Alan Cox wrote: Are FireWire (and USB) disks always detected in the same order? Or does it behave like ADB, where you never know which mouse/keyboard is which mouse/keyboard? USB disks are required (haha etc) to have serial numbers. Firewire similarly has unique disk identifiers. How about for other device classes? -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! Unix gives you enough rope to shoot yourself in the foot. http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problem with make xconfig and tcl/tk 8.3 (and fix)
I have tcl/tk8.3.2 installed and make xconfig (for both 2.2.18 and 2.4.2) just hang. I've been told by the listed maintainer that a new GUI is on its way and the existing make xconfig is orphaned, but this does not solve the immediate problem. I have therefore fixed this problem myself and have patches for header.tk and tail.tk if anyone is interested. Essentially the fix is to replace all the 'exec ...' commands with native Tcl ones. I have also enhanced the help system so that the help is cached internally on startup and its existence is used to control the state of the help button, this makes getting help much faster and more reliable (RTFM messages are no longer needed). The help itself now has a blue title that points back to the originating entry. I'm happy to provide these if anyone is interested, I have tested them with tcl/tk8.2.0 as well and as far as I can see they work fine. The sizes are wc -l *patch* 322 header.tk.patch 39 tail.tk.patch-2.2.18 61 tail.tk.patch-2.4.2 I'm not subscribed to the list so please cc replies to me if you wish. Thanks, Simon Geard. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
Richard Gooch wrote: Erm, let's start again. My central point is that you can use devfs names to reliably figure out what kind of device a FD is, as a cleaner alternative to comparing major numbers. Therefore, I'm challenging the notion that you need to reserve magic major numbers in order to distinguish devices. Noone in this tree has made that claim. Everyone agree it's butt-ugly. However, your solution is by and large just as butt-ugly. -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! Unix gives you enough rope to shoot yourself in the foot. http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
