Re: LANANA: To Pending Device Number Registrants
On 16 May 2001 01:56:23 +0200, Tim Jansen wrote: > On Wednesday 16 May 2001 01:16, David Brownell wrote: > >Only if it's augmented by additional device IDs, such as the > >"what 's the physical connection for this interface" sort of > >primitive that's been mentioned. > >[...] > > I suppose that for network interface names, some convention for > > interface ioctls would suffice to solve that "identify" step. PCI > > devices would return the slot_name, USB devices need something > > like a patch I posted to linux-usb-devel a few months back. > > At this point of the discussion I would like to point to the Device Registry > patch (http://www.tjansen.de/devreg) that already solves these problems and > offers stable device ids for the identification of devices and finding their > /dev nodes. > > The devreg device id has four components: the bus identifier, the location of > the device (for pci bus number and slot number, for usb the bus number and a > list of port numbers), a model (product and device id) and, if available, a > serial number. > With the matching algorithm from the libdevreg library you can correctly > identifiy after a hotplug action or reboot > - each device that has a serial numberas most of the better USB devices do, > even if it location has changed > - a device without a serial number whose location has not changed > > If you have a device without serial number and you changed its location the > device id can be used for a guess that is correct as long as you dont have > two devices of the same kind (same product and vendor ids). Hmm. It's interesting to me that there have been no replies discussing Tim's code. Are any of you looking at it or do you simply think it is inconsequential and deserves to be ignored? Or, perhaps folks feel that it is off-topic? Since, as Alan mentioned, the lack of device serial numbers for USB mice and keyboards means that the only way to implement a relatively stable assignment of USB input devices to a quasi-multiuser system with multi-headed displays is by paying attention to USB topology, I would like us to explore any implementation that includes this support. As Linus mentioned, this approach is unreliable, but it's all we have for these devices -- Topology can be disturbed by a variety of events (plugging a hub into a different host-controller port, etc). 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: ((struct pci_dev*)dev)->resource[...].start
Jeff Garzik writes: > "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 )? 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). Well, I have a bus driver. Just how do I get a bus number? My hardware comes up as a regular device, then mutates into a bridge when I flip a bit in a config register. The header even changes from type 1 to type 2. The class code is always the same, a bridge device, but not PCI-to-PCI. It's kind of like hot-plug PCI over a network, with all sorts of extra alignment restrictions on address space allocation. So maybe this card is on bus 42. I need a secondary bus number, plus a few more in case there are more bridges downstream. I can't just grab 42..44 because they might be used elsewhere, and I can't just grab 253..255 either because that upsets the whole system of bus number assignment being done by carving up the space granted to upstream bridges. BTW, is there any reason why the primary bus register of a bridge would have to be set correctly? I have to set mine equal to the secondary bus register to keep the hardware happy. > 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. Hmmm. I can use device-specific config space registers to change the size of a BAR. (or limit & base, whatever) Say I want to have 512 MB, but the bridge upstream only has 128 MB allotted to it. How do I fix this? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Sound ioctl's
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
#include
#include
#include
#include
#include
#include
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, )<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;
}
patch-2.2.19.gz
I just patched my 2.2.18 kernel. After I did a make dep I got the following message. Any ideas what does this mean? md5sum: WARNING: 11 of 12 computed checksums did NOT match Joe Acosta home: [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: 2.2.20pre1: Problems with SMP
On Wed, May 16, 2001, Shane Wegner <[EMAIL PROTECTED]> wrote: > On Wed, May 16, 2001 at 12:56:55PM -0700, Johannes Erdfelt wrote: > > Could you try this patch? It applies on top of 2.2.20pre1 > > > > It also cleans up a couple of comments > > That fixes it alright. Excellent. Alan, could you apply the patch to 2.2.20pre2? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.4-ac9 problems on Iwill KK266
Hello I have been trying to get 2.4.x to boot on my machine for sometime. I finally got ac9 to boot today but I had to change the Processor Opts from Athlon/K7/etc to PII/Celeron. I am running on an Iwill KK266 board with a duron 800, 384 megs of RAM, SB Live X-Gamer, Adaptec 2910 and 2940UW, tnt2, and linksys Etherfast 10/100 nic. I run Debian sid. I have been running 2.2.19 for sometime with no troubles. 2.4.x with k7 opts always would opps out while runing rcS scripts and never would get past single user. More info available upon request Wayne "bigguy" Johnson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 problems
First this my configuration: Kernel 2.4.4 / Athlon 650 May 17 05:38:45 m kernel: hdd: IOMEGA ZIP 100 ATAPI, ATAPI FLOPPY drive May 17 05:38:45 m kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 May 17 05:38:45 m kernel: ide1 at 0x170-0x177,0x376 on irq 15 May 17 05:38:45 m kernel: hda: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=29314/64/32, UDMA(100) May 17 05:38:45 m kernel: hdc: ATAPI DVD-ROM drive, 512kB Cache, UDMA(33) May 17 05:38:45 m kernel: Uniform CD-ROM driver Revision: 3.12 May 17 05:38:45 m kernel: hdd: 98304kB, 196608 blocks, 512 sector size, May 17 05:38:45 m kernel: hdd: 98304kB, 96/64/32 CHS, 4096 kBps, 512 sector size, 2941 rpm then i did the following: [root@m /mnt]# mount /dev/hdd4 /mnt/zip [root@m /mnt]# cp /linux-2.4.4.tar.bz2 /mnt/zip [root@m /mnt]# sync May 17 05:42:20 m kernel: hdd: lost interrupt May 17 05:42:20 m kernel: ide-floppy: CoD != 0 in idefloppy_pc_intr May 17 05:42:20 m kernel: hdd: ATAPI reset complete May 17 05:43:10 m kernel: hdd: lost interrupt May 17 05:43:10 m kernel: ide-floppy: CoD != 0 in idefloppy_pc_intr May 17 05:43:10 m kernel: hdd: ATAPI reset complete After few minutes and lots of that messages I ejected the zip. May 17 05:46:19 m kernel: end_request: I/O error, dev 16:44 (hdd), sector 56533 May 17 05:46:19 m kernel: ide-floppy: hdd: I/O error, pc = 2a, key = 2, asc = 3a, ascq = 0 After another 1 minute of this repeated messages I push reset . Any ideeas ? -- TFM Group Romania , Linux division Mihai Moldovanu http://www.tfm.ro/ http://portal.tfm.ro/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
write() writes too many bytes?
OK, I know this is bizarre and probably some goof on my part, but it is just too weird for me to guess at further: My program write()s 2- and 4- byte chunks or data to a file (for a WAV header). When the data being written contains an 0xff byte, it is apparently written to disk as 2 bytes: 0x81ff. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] wrote: [lots of sensible comments to get this discussion "on track"] > So we have: user space has file names and uses open() or mount(). > Kernel space has device paths. > > In principle the kernel could just number the devices it sees 1,2,... > and export information about them, so that user space can choose > the right number. > The part about exporting information is good. User space needs to > be able to ask if a certain beast is a CD reader, and if so what > manufacturer and model. > But the part about numbering 1,2,... may not be good enough, e.g. > because it does not survive reboots. If we remain Unix-like and use > device nodes in user space to pair a file name with a number, then > it would be very nice if the number encoded the device path uniquely. > Many programs expect this. > It cannot be done in all cases, but a good approximation is obtained > if the number is a hash of the device path. In so far the hash is > collision free we obtain numbers that stay unique over a reboot. I think here we might learn from the comments that people made about how AIX and OSF/1/Tru64 have been doing this. You want the relation between a given /dev/xyz node and the corresponding device in the kernel to be relatively stable from the perspective of the user, so you can use it to implement device naming and access policies. What "stable" means technically is a matter of policy, since it depends very much on the perspective of the user. You also want the relation between a given /dev/xyz node and the major/minor number of the related device to be "fixed", so you don't need to recreate all device nodes on every boot. The issue is then how to establish the relation between major/minor numbers and (potentially very dynamic) kernel-internal device entities, in such a way that the type of stability desired by the user is provided. As people noted, the mechanism used by AIX and Tru64 is essentially to have this relationship established by a user-level tool using a configuration file with policy information, and a status file to maintain state information across reboots. This tool can implement any policy it likes, which means we can avoid all the policy discusions where the kernel is concerned, and can instead focus on methods. For the people who want things to be backward compatible, it would be sufficient to implement a default tool that will set all the major/minor numbers exactly like they are now, so all existing device nodes will keep working as they did. In order to support hot plugging of devices, I suppose this tool should either run as a daemon, or set itself up to be called by the kernel whenever something happens. (I think I would prefer the daemon...) Sort of like /sbin/hotplug. The next issue to discuss is then how to shape the mechanism by which the device manager tool and the kernel exchange information on what devices are out there, and what major/minor numbers each should be assigned. The sort of information that a device manager might want to use, depending on how it is implemented and configured, would include such things as: device driver id, I/O bus, I/O port, IRQ nr, SCSI card/bus/id/lun, partition id, serial number, device model/type, filesystem label, filesystem UUID, phase of the moon, etc, etc. Basically, anything that a driver or related subsystem can come up with that might help identify a device or resource in any particular situation, depending on user preferences. I think this may fit somewhere in /proc/sys/dev or thereabout. The big advantage of this approach is basically that we can continue to use the good old device nodes in the filesystem as we have done for the last 30 years, with all the advantages, but without the major/minor number allocation troubles. Hmm, this all sounds too simple. I must be talking nonsense. Please wake me up. ;-) -- Willem Konynenberg <[EMAIL PROTECTED]> I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question -- Charles Babbage - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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][RFC] more initcall cleanups
Linus, I've done a bit more cleaning the device initialization
up (beginning of chr_dev_init()) and results were, well, interesting.
a) I2C stuff got converted to module_init() nicely. That took
a lot of cruft away.
b) init order is preserved. However, that worked only because
none of the i2c initialization functions touch stuff from random.c
c) I had to put i2c before char to preserve the ordering.
Not a big deal, but I'm somewhat at loss here - how to do it without
really ugly drivers/Makefile. Suggestions?
d) if we set CONFIG_I2C to 'y' we don't include drivers/i2c
into subdir-m. However, having i2c-core in kernel and the rest done as
modules is OK with i2c itself. And I seriously suspect that it's
a common situation. Am I right assuming that correct way to deal with
that is to put i2c into mod-subdirs?
e) looks like rand_initialize() is in the same class as handling
VFS/VM/etc. caches - global infrastructure. It definitely should be
called before all other drivers. Notice that old device_init() was asking
for trouble - it called parport_init() before chr_dev_init() (which calls
rand_initialize()), so if somebody would try to feed some entropy into
pool during the parport_init() we would get an interesting (and hard
to understand) problem. Maybe we should move the call into basic_setup()?
Comments?
Very preliminary patch follows. Please, _don't_ apply it in that
form - drivers/Makefile is just too ugly.
Al
diff -urN S5-pre3-init-0/drivers/Makefile S5-pre3-init/drivers/Makefile
--- S5-pre3-init-0/drivers/Makefile Wed May 16 16:26:35 2001
+++ S5-pre3-init/drivers/Makefile Wed May 16 20:47:52 2001
@@ -9,8 +9,13 @@
mod-subdirs := dio mtd sbus video macintosh usb input telephony sgi i2o ide \
scsi md ieee1394 pnp isdn atm fc4 net/hamradio i2c acpi
-subdir-y :=parport char block net sound misc media cdrom
-subdir-m :=$(subdir-y)
+subdir-y :=parport
+subdir-m :=parport
+
+subdir-$(CONFIG_I2C) += i2c
+
+subdir-y +=char block net sound misc media cdrom
+subdir-m +=char block net sound misc media cdrom
subdir-$(CONFIG_DIO) += dio
@@ -40,7 +45,6 @@
# CONFIG_HAMRADIO can be set without CONFIG_NETDEVICE being set -- ch
subdir-$(CONFIG_HAMRADIO) += net/hamradio
-subdir-$(CONFIG_I2C) += i2c
subdir-$(CONFIG_ACPI) += acpi
include $(TOPDIR)/Rules.make
diff -urN S5-pre3-init-0/drivers/char/Makefile S5-pre3-init/drivers/char/Makefile
--- S5-pre3-init-0/drivers/char/MakefileWed May 16 16:26:36 2001
+++ S5-pre3-init/drivers/char/Makefile Wed May 16 20:39:26 2001
@@ -16,7 +16,7 @@
O_TARGET := char.o
-obj-y += mem.o tty_io.o n_tty.o tty_ioctl.o raw.o pty.o misc.o random.o
+obj-y += random.o mem.o tty_io.o n_tty.o tty_ioctl.o raw.o pty.o misc.o
# All of the (potential) objects that export symbols.
# This list comes from 'grep -l EXPORT_SYMBOL *.[hc]'.
diff -urN S5-pre3-init-0/drivers/char/mem.c S5-pre3-init/drivers/char/mem.c
--- S5-pre3-init-0/drivers/char/mem.c Wed May 16 16:26:36 2001
+++ S5-pre3-init/drivers/char/mem.c Wed May 16 20:48:51 2001
@@ -26,9 +26,6 @@
#include
#include
-#ifdef CONFIG_I2C
-extern int i2c_init_all(void);
-#endif
#ifdef CONFIG_VIDEO_DEV
extern int videodev_init(void);
#endif
@@ -615,10 +612,6 @@
if (devfs_register_chrdev(MEM_MAJOR,"mem",_fops))
printk("unable to get major %d for memory devs\n", MEM_MAJOR);
memory_devfs_register();
- rand_initialize();
-#ifdef CONFIG_I2C
- i2c_init_all();
-#endif
#if defined (CONFIG_FB)
fbmem_init();
#endif
diff -urN S5-pre3-init-0/drivers/char/random.c S5-pre3-init/drivers/char/random.c
--- S5-pre3-init-0/drivers/char/random.cWed May 16 16:26:36 2001
+++ S5-pre3-init/drivers/char/random.c Wed May 16 20:40:12 2001
@@ -1380,7 +1380,7 @@
}
}
-void __init rand_initialize(void)
+static int __init rand_initialize(void)
{
int i;
@@ -1404,7 +1404,10 @@
memset(_timer_state, 0, sizeof(struct timer_rand_state));
memset(_timer_state, 0, sizeof(struct timer_rand_state));
extract_timer_state.dont_count_entropy = 1;
+ return 0;
}
+
+__initcall(rand_initialize);
void rand_initialize_irq(int irq)
{
diff -urN S5-pre3-init-0/drivers/i2c/i2c-algo-bit.c
S5-pre3-init/drivers/i2c/i2c-algo-bit.c
--- S5-pre3-init-0/drivers/i2c/i2c-algo-bit.c Sun Apr 1 23:56:45 2001
+++ S5-pre3-init/drivers/i2c/i2c-algo-bit.c Wed May 16 20:54:07 2001
@@ -607,7 +607,7 @@
return 0;
}
-int __init i2c_algo_bit_init (void)
+static int __init i2c_algo_bit_init (void)
{
printk("i2c-algo-bit.o: i2c bit algorithm module\n");
return 0;
@@ -618,7 +618,6 @@
EXPORT_SYMBOL(i2c_bit_add_bus);
EXPORT_SYMBOL(i2c_bit_del_bus);
-#ifdef MODULE
MODULE_AUTHOR("Simon G. Vogl <[EMAIL
Re: locked 3c905B with 2.4.5pre2
Julian Anastasov wrote: > > eth0: Interrupt posted but not delivered -- IRQ blocked by another device? This is a failure of the APIC interrupt controller in the 2.4 kernel. You'll need to boot your kernel with the `noapic' LILO option. Or run -ac kernels, which have a software workaround which fixes the problem. Rumour has it that the APIC fix will be merged into Linus' tree very soon. It needs to be - one of the more important ethernet drivers is basically unviable on x86 SMP in 2.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/
Re: 2.2.20pre1: Problems with SMP
On Wed, May 16, 2001 at 12:56:55PM -0700, Johannes Erdfelt wrote: > > Could you try this patch? It applies on top of 2.2.20pre1 > > It also cleans up a couple of comments That fixes it alright. Shane -- Shane Wegner: [EMAIL PROTECTED] http://www.cm.nu/~shane/ PGP: 1024D/FFE3035D A0ED DAC4 77EC D674 5487 5B5C 4F89 9A4E FFE3 035D - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: vfat large file support
Followup to: <[EMAIL PROTECTED]> By author:Felix von Leitner <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > I can't copy a file larger than 2 gigs to my vfat partition. > What gives? 2.4.4-ac5 kernel. My cp copies 2 gigs and then aborts. > > $ echo foo >> file_on_vfat_partition > > causes the shell to become unresponsive and consume lots of CPU time. > VFAT doesn't support files larger than 2 GB. -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/
Hard freezes copying from (but not to) a 80GB Maxtor HD on a HPT370 channel
I have been happily accumulating some files on an 80GB Maxtor HD sitting on /dev/hdg mounted as /arc. There are 2 other drives on the HPT370 (KA7-100 MB with TY Bios) and 2 on the main mother board IDE controller. The system is currently running 2.4.3-ac14. It has been solid as a rock and I have experienced no disk problems. I don't think I have crashed in the past 4 months running a ever changing series of kernels and changing HW from time to time. Today I tried to cp a directory from /arc to /fs2, a file system on hde, the primary channel of the HPT370. The system immediately (almost, a few files were copied) froze solid. I have tried to get to the bottom of this and have determined that I can copy a 2GB test directory to every drive in the system. At first I thought that I could copy safely off /arc if it went to a drive not on the HPT370 controller. Trying to copy to a test directory to /fs (/dev/hdb) worked and copying it to /fs2 (/dev/hde) caused an almost immediate freeze. However, when I tried to cp 10GB from /arc to /fs while a tape backup (of a partition on /dev/hda) was going on it once again (almost) immediately froze the system solid. The problem seems to only relate to the 80GB Maxtor. However, I haven't yet done quite enough experiments to conclude that (gotta get real work done on the machine so the reboots forced by the freezes limit how many tests I can squeeze in in a day ) I can apparently copy data to the drive to beat the band and I have regularly accessed files on the drive (e.g., to play an mp3) but something about a mass copy is fatal. I consed up a 2.4.4-ac9 kernel and verified that the problem persists in that kernel too. Can someone point me in the right direction? I have been assuming that it is some driver issue, but that is just an assumption. Could it be the drive? It is pretty new (a few months old). Unfortunately I must leave town for a while in a few days. I'd love to get on top of this before I go if possible. I'd appreciate any hints or similar data other could provide. TIA, Dick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
Hello, This is known issue. cmpci driver included in the kernel is way too old. I'm using newer driver (revision 4.14) and it works just fine. It was announced on lkml long time ago. Last time I checked there was even newer driver - 5.64. The one in the kernel has version 2.41. Is it possible to include the new driver? This is the homepage: http://members.home.net/puresoft/cmedia.html -- DV - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
vfat large file support
I can't copy a file larger than 2 gigs to my vfat partition. What gives? 2.4.4-ac5 kernel. My cp copies 2 gigs and then aborts. $ echo foo >> file_on_vfat_partition causes the shell to become unresponsive and consume lots of CPU time. Felix - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
Just a "me, too" here. I see this when using the in-kernel driver. I'm now using... 4.12, I think. At any rate, the error doesn't occur, or at least occurs to rarely as to escape notice, with this driver. Might I suggest the kernel's version be upgraded? The updated driver was posted here on lkml some time ago. On Wed, May 16, 2001 at 08:02:06PM -0300, Rik van Riel wrote: > 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/ -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: sym53c8xxx.c timer handling
Gerard, LKML
The attached patch tweaks the sym53c8xx timeout timer handling a bit.
Is it correct?
It works with interrupts off (we need a reboot notifier to iterate the
hosts list, with IRQs off) and doesn't delay() 5 seconds in worst case.
Is there any reason this patch won't work? It seems OK to me.
Tim
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
--- /home/users/admin/C26/III/linux-2.2/drivers/scsi/sym53c8xx.cTue May 15
19:14:48 2001
+++ /usr/src/linux/drivers/scsi/sym53c8xx.c Wed May 16 22:52:12 2001
@@ -2265,7 +2265,6 @@
**
*/
struct usrcmd user; /* Command from user*/
- volatile u_char release_stage; /* Synchronisation stage on release */
/*
** Fields that are used (primarily) for integrity check
@@ -5884,7 +5883,12 @@
** start the timeout daemon
*/
np->lasttime=0;
- ncr_timeout (np);
+#ifdef SCSI_NCR_PCIQ_BROKEN_INTR
+ np->timer.expires = ktime_get((HZ+9)/10);
+#else
+ np->timer.expires = ktime_get(SCSI_NCR_TIMER_INTERVAL);
+#endif
+ add_timer(>timer);
/*
** use SIMPLE TAG messages by default
@@ -7244,20 +7248,17 @@
static int ncr_detach(ncb_p np)
{
- int i;
+ unsigned long flags;
printk("%s: detaching ...\n", ncr_name(np));
/*
-** Stop the ncr_timeout process
-** Set release_stage to 1 and wait that ncr_timeout() set it to 2.
+** Stop the ncr_timeout process - lock it to ensure no timer is running
+** on a different CPU, or anything
*/
- np->release_stage = 1;
- for (i = 50 ; i && np->release_stage != 2 ; i--) MDELAY (100);
- if (np->release_stage != 2)
- printk("%s: the timer seems to be already stopped\n",
- ncr_name(np));
- else np->release_stage = 2;
+ NCR_LOCK_NCB(np, flags);
+ del_timer(>timer);
+ NCR_UNLOCK_NCB(np, flags);
/*
** Reset NCR chip.
@@ -8613,23 +8614,11 @@
{
u_long thistime = ktime_get(0);
- /*
- ** If release process in progress, let's go
- ** Set the release stage from 1 to 2 to synchronize
- ** with the release process.
- */
-
- if (np->release_stage) {
- if (np->release_stage == 1) np->release_stage = 2;
- return;
- }
-
#ifdef SCSI_NCR_PCIQ_BROKEN_INTR
- np->timer.expires = ktime_get((HZ+9)/10);
+ mod_timer(>timer, ktime_get((HZ+9)/10));
#else
- np->timer.expires = ktime_get(SCSI_NCR_TIMER_INTERVAL);
+ mod_timer(>timer, ktime_get(SCSI_NCR_TIMER_INTERVAL));
#endif
- add_timer(>timer);
/*
** If we are resetting the ncr, wait for settle_time before
Re: LANANA: To Pending Device Number Registrants
To inject a bit of concrete into this discussion, I note that block devices with dynamically assigned don't work with CONFIG_DEVFS and devfs=only. Block devices -require- majors currently, due to those !@#!@# arrays. However, devfs_register_blkdev always returns zero when devfs=only, even if its a block device and a dynamic major is requested. -- 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
On Thu, May 17, 2001 at 12:26:12AM +0100, 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. "haha etc" indeed. We've just purchased and tested a BusLink 20GB USB disk. Works fine with the driver we found. Great, in fact. But no serial number at all. Joel -- "What do you take me for, an idiot?" - General Charles de Gaulle, when a journalist asked him if he was happy. http://www.jlbec.org/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
[EMAIL PROTECTED] [[EMAIL PROTECTED]] wrote: > In principle the kernel could just number the devices it sees 1,2,... > and export information about them, so that user space can choose > the right number. > The part about exporting information is good. User space needs to > be able to ask if a certain beast is a CD reader, and if so what > manufacturer and model. > But the part about numbering 1,2,... may not be good enough, e.g. > because it does not survive reboots. If we remain Unix-like and use > device nodes in user space to pair a file name with a number, then > it would be very nice if the number encoded the device path uniquely. > Many programs expect this. > It cannot be done in all cases, but a good approximation is obtained > if the number is a hash of the device path. In so far the hash is > collision free we obtain numbers that stay unique over a reboot. > > Andries I disagree that the kernel should apply sequence numbers as devices are found or hash path information into the device name. I am unclear of the need for the hashing the path into the name. In the ptx operating system I previously worked on we ID'd everything that we could get a UUID from and one's that we could not we generated a pseudo one. We also split the UUID space up on config type. This is similar to the discussion in Andreas's mail. Non-id'd devices could possibly slip, but ID'd ones did not. In user space we allowed the user to select any name for a device (the user space to kernel connection was made by UUID. The solution worked on SCSI and FC based devices (Linux obviously deals with many more device name spaces). I thought with devfs, devreg, and non allocated major, minors. A similar capability would be possible. The "/dev" usage would not need to know the path, but methods would be available to make the relationship when needed. -Mike -- Michael Anderson [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
> Yes, it's broken if someone writes a cabbage dicer driver and uses > "cd" as the leaf node name for devfs. > > Yes, it's broken if someone writes a cabbage dicer driver and uses > the same major as the IDE CD-ROM or SCSI CD-ROM drivers. The difference is one is a kernel interface magic cookie (be it a variable length one with a 7bit ascii mapping that happens to relate to it, or a short constnt) the other is user policy and has no business being set in a spec - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
> > USB disks are required (haha etc) to have serial numbers. Firewire similarly > > has unique disk identifiers. > > How about for other device classes? Keyboards and mice dont which is a real pig because it prevents you using dual head, two usb keyboards and 2 usb mice for a dual user box (assuming someone fixed the console code mess to cope with multiple console users as a concept) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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. > reset/clear CMOS with jumper. I get this kind of instability each time I have to boot to win9x (with latest and greatest via drivers) and back to linux. Just of sudden linux freezes or if I have apcid running sometimes it oops' on boot sometimes later ... lots of defunc kacpid ... threads. looks like VIA drivers do something to hardware (or maybe only ACPI part of hardware ... I don't know.) and linux can't handle hardware is this new "after win9x" state ... reset/clear CMOS with jumper helped. MB ABit KT7A-RAID 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40) VT82C686b actually :) 00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) 00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40) 00:08.0 Ethernet controller: Bridgecom, Inc: Unknown device 0985 (rev 11) 00:0f.0 Multimedia audio controller: Creative Labs SB Live! EMU1 (rev 07) 00:0f.1 Input device controller: Creative Labs SB Live! (rev 07) 01:00.0 VGA compatible controller: ATI Technologies Inc: Unknown device 5144 > > - 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/ -- Zilvinas Valinskas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 in 2.4.4-ac9 (mm/slab.c)
> 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?) Its a deliberate debugging trap. > #if DEBUG > if (cachep->flags & SLAB_POISON) > if (kmem_check_poison_obj(cachep, objp)) > BUG(); > ^^ This one is triggered Someone freed memory and then scribbled on it. The first thing useful here is to know which drivers you were using shortly before the oops - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: "clock timer configuration lost" on Serverworks chipset
> 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? There is a notional off by one in the check at least by the rules of the original chip which do allow the overflow value to be visible momentarily. Later -ac checks for > not >= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: your mail
On Wed, May 16, 2001 at 08:05:38AM -0700, siva prasad wrote: > Is it true that the ipc calls like > msgget(),shmget()... > are not really system calls? No, they all use a system call, but the system call is the same for all functions. > Cos in the file "asm/unistd.h" where the > system calls are listed as __NR_xxx we dont find > the appropriate listing for the ipc calls. > What I guessed was that all the ipc calls are > clubbed under the 'int ipc()' system call and this > is well listed in the "asm/unistd.h" Right, they all use __NR_ipc. See sys_ipc() in arch/i386/kernel.sys_i386.c, especially the comment right above the function... > Could some one explain why the ipc is implemented > this way rather that implementing them as individual > system calls as in UNIX. Probably because the original designer liked it this way and nobody cared enough to do it otherwise. > Or is it the same way in UNIX I don't know, I don't have Unix source available. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
The LANANA discussion has forked into a forest of vaguely related discussions. If I am not mistaken the only real question is how user space and kernel space communicate device identities. Here "user space" is very different from "users". Devices have a device path and device contents. For the user it is very desirable to recognize things by contents. One invents labels and similar schemes, both readable with the eye and readable with software. But devices vary quite a lot and labeling schemes vary quite a lot and user needs vary quite a lot. Clearly, recognizing a device by contents is something that belongs to user space. Of course the kernel can make functions available to simplify the work of a device manager, but the actual work of making the correspondence between the identity of a device as seen by the user and the device path belongs to user space. Be it a boot-time setup script working from a data base, or a daemon. (A somewhat weaker function also belongs to user space: Even if the user has not specified a name for a device it may be that the device has a serial number or other recognizable information, so that user space can guess or be sure that a certain device is the same as something seen earlier, perhaps before the last reboot.) That was the user. She thinks about "my boot partition". And mount sees "UUID=e70bde8e-34d7-11d... /boot ext2 ..." or "LABEL=Boot /boot ext2 ..." and searches /proc/partitions for things that, when interpreted as an ext2 filesystem, have the specified UUID or label. The communication between user space and kernel is not in terms of device "contents", since the kernel doesnt know about such things. The kernel knows only one thing: the device path. (the driver used, together with all parameters, the port address, the SCSI ID, the disk subinterval, ...) But this path is a very complicated object. Moreover, it contains a lot of items that the user has never heard of. It is a bad idea to try to use such paths. So we have: user space has file names and uses open() or mount(). Kernel space has device paths. In principle the kernel could just number the devices it sees 1,2,... and export information about them, so that user space can choose the right number. The part about exporting information is good. User space needs to be able to ask if a certain beast is a CD reader, and if so what manufacturer and model. But the part about numbering 1,2,... may not be good enough, e.g. because it does not survive reboots. If we remain Unix-like and use device nodes in user space to pair a file name with a number, then it would be very nice if the number encoded the device path uniquely. Many programs expect this. It cannot be done in all cases, but a good approximation is obtained if the number is a hash of the device path. In so far the hash is collision free we obtain numbers that stay unique over a reboot. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACP Modem (Mwave)
> Please throw any comments, questions, suggestions, hard objects this way...
First obvious comments
+ while (uCount-- != 0) {
+ unsigned short val_lo, val_hi;
+ cli();
+ val_lo = InWordDsp(DSP_MsaDataISLow);
+ val_hi = InWordDsp(DSP_MsaDataDSISHigh);
+ put_user(val_lo, pusBuffer++);
+ put_user(val_hi, pusBuffer++);
+ sti();
+
1. Please use spinlocks not cli/sti as they will go away probably in 2.5
2. You can't touch user space holding interrupts off as it can't handle
page faults
+void PaceMsaAccess(unsigned short usDspBaseIO)
+{
+ schedule();
+ udelay(100);
+ schedule();
+}
If you are trying to be friendly then add
if(current->need_resched)
schedule()
just to be more efficient
+BOOLEAN dsp3780I_GetIPCSource(unsigned short usDspBaseIO,
+ unsigned short *pusIPCSourc
s/BOOLEAN/int
s/TRUE/0
s/FALSE/-Eappropriateval
would be more in keeping. Not a bug by any means
The ioctl locking seems wrong. It doesnt look like the DSP accesses are
locked against one another and you can issue multiple ioctls in parallel in
different threads
If mwave_read/write do nothing then they should really be returning an error
code. 0 is EOF, count on write is success.
+BOOLEAN smapi_init()
you want (void) or you get compiler warnings on some compiler revisions
+ PRINTK_1(TRACE_SMAPI, "smapi::smapi_init entry\n");
+
+ usSmapiID = CMOS_READ(0x7C);
+ usSmapiID |= (CMOS_READ(0x7D) << 8);
CMOS reads/writes must be done holding the lock against other cmos users
+int Initialize(THINKPAD_BD_DATA * pBDData)
Please dont have globals with names so generic
Hope those are useful
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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:
>
> Alan Cox writes:
> > > 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) {
> >
> > drivers/kitchen/bluetooth/vegerack/cd
> >
> > its the cabbage dicer still ..
>
> No, because it violates the standard. Just as we can define a major
> number to have a specific meaning, we can define a name in the devfs
> namespace to have a specific meaning.
>
> Yes, it's broken if someone writes a cabbage dicer driver and uses
> "cd" as the leaf node name for devfs.
>
> Yes, it's broken if someone writes a cabbage dicer driver and uses
> the same major as the IDE CD-ROM or SCSI CD-ROM drivers.
>
But unlike the latter case, your case isn't even self-enforcing.
Furthermore, it puts a lot of future restrictions on the namespace, and
take it from me, you don't want to do that.
That, of course, is in addition to everything else...
-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] rootfs (part 1)
On Thu, 17 May 2001, Alan Cox 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. > > Surely this is getting right into 2.5 stuff. Maybe. I still think that it's local enough to be tolerable in 2.4, but postponing it until 2.5 is not a big deal. I'll put that (and the rest of rootfs stuff) on anonftp and post CFT. I'd appreciate review of that code once the splitup is done, if you have time for that. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
hpa wrote: > > 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. Bulk-only USB storage is required to have serial numbers. E.g., Zip drives, probably USB hard drives and CDs. Drives that use CBI (control/bulk/interrupt) transport (mostly floppies) are not required to have serial numbers. (Cost thing, of course.) > How about for other device classes? Mice? no way. Keyboards? nope. Webcams? nope. Printers? optional. Audio? no. Communication? not mentioned in the spec. Hub? not mentioned in the spec. ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
Richard Gooch wrote: > > OK. How do you figure on dealing with the problem of multiple > high-level drivers talking to the same device? How does sr.o "know" > that this is also a CD-RW? How does sg.o "know" that this is also a > tape? > At some point something talks to the device -- in this case, it's the SCSI layer. Follow the interfaces in the kernel and it becomes obvious. > Where does the responsibility lie for figuring out the capabilities? > > Further, which device node/fs/driver exports the capability list? > > And what about locking between drivers? Orthogonal issue. You may want a locking mechanism, but it almost certainly should not be automatic. Note that especially ide-scsi is a good example on how *not* to do things. The fact that you have to choose one of two interfaces for different operations (I can't use a CD-writer in the default configuration!) is insane. -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
Alan Cox writes:
> > 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) {
>
> drivers/kitchen/bluetooth/vegerack/cd
>
> its the cabbage dicer still ..
No, because it violates the standard. Just as we can define a major
number to have a specific meaning, we can define a name in the devfs
namespace to have a specific meaning.
Yes, it's broken if someone writes a cabbage dicer driver and uses
"cd" as the leaf node name for devfs.
Yes, it's broken if someone writes a cabbage dicer driver and uses
the same major as the IDE CD-ROM or SCSI CD-ROM drivers.
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
> 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) {
drivers/kitchen/bluetooth/vegerack/cd
its the cabbage dicer still ..
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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, H. Peter Anvin wrote: > 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? Note that this whole decision hinges on a fact that simply isn't _true_. You simply _cannot_ get the physical location of many devices. Sometimes the topology of the bus is basically anonymous - there _is_ no location. People had better just accept this. Don't get hung up about where something is. 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)
> 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. I think you have a major tool problem. bash-2.04$ size mm/shmem.o textdata bss dec hex filename 7422 572 079941f3a mm/shmem.o bash-2.04$ size fs/ramfs/ramfs.o textdata bss dec hex filename 3185 368 03553 de1 fs/ramfs/ramfs.o Never trust ls -l size for binaries, its very very unrelated. So ramfs is 3553 bytes, shmem.o in total is 8K on current -ac. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
> 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. Let me guess 'ide=nodma' fixes that ? > 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 Since when - the VIA driver in -ac has not changed for a very long time > 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? it shouldnt ever misdetect - thats a bug. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.20pre2aa1
> 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). I think so. Im still not convinced the bug is anything but theoretical but its on my list and if it makes sense then Andrea's patch will go in - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
[Cc: list trimmed because I figure people are getting tired of us:-] H. Peter Anvin writes: > Richard Gooch wrote: > > > > H. Peter Anvin writes: > > > 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. > > > > So you'd prefer some kind of capability list? OK. How do you figure on dealing with the problem of multiple high-level drivers talking to the same device? How does sr.o "know" that this is also a CD-RW? How does sg.o "know" that this is also a tape? Where does the responsibility lie for figuring out the capabilities? Further, which device node/fs/driver exports the capability list? And what about locking between drivers? 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
On Thu, 17 May 2001, 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. Well, as that doesn't actually work out in practice, the good news is that USB at least _tries_ to always walk the tree the same way when detecting devices, so if you don't change where your devices are in the topologu they should show up in similar places. Of course, "not changing topology" also means things like not powering off devices with external power supplies etc.. The serial numbers are probably not that reliable. 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
Richard Gooch wrote: > > H. Peter Anvin writes: > > 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. > > So you'd prefer some kind of capability list? > Yes. -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: ide-floppy
> Whenever I boot (2.4.4-ac6) I get this error message if there is a zip > disk in the drive. Does it work with ide-scsi ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: LVM 1.0 release decision
> > code and your new release _before_ you do that. > > The new code *can* automagically read and deal with 0.8 created VGDAs. > What are you refering too in detail here? Yes. This is good The important thing is that the external interface and on disk format dont break - the code can be broken/mended repeatedly the ABI is rather harder to cure > In the LV struct we can change it easily, because we just need the minor > number which will nicely fit into the 32 bit we have. Ok. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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)
> 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. I think ramfs is an incredibly flawed example right now - precisely because it has no error cases. ramfs with the size limiting is a brilliant fs for embedded/pda work as well as an example that shows error paths - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: > > > > 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. So you'd prefer some kind of capability list? 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
H. Peter Anvin writes: > Richard Gooch wrote: > > 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. 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. I suspect you're thinking about a different problem, which is finding out what a device can do. Implementing some kind of capability list may well be a good approach to *that* problem. There are some details to figure out, like how multiple drivers interact with each other. They could be tricky. Now, with the above said, what operations do you think I'm prohibiting? Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
Richard Gooch wrote: > > 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/
Re: [PATCH] rootfs (part 1)
> 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. Surely this is getting right into 2.5 stuff. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [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: 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: 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
> 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)
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: [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: ((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: ((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:[]
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: [] [] [] [] []
[] [] [] [] []
Code: 0f 0b f7 c5 00 04 00 00 74 2a b8 a5
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/
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/
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)
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/
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: ((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 )? 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: 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: [PATCH] drivers/char/serial.c bug in ST16C654 detection
Anyone know where Ted Tso is? He hasn't posted in several weeks.
Alan, will you put this in -ac? This patch fixes a bug in serial.c
that causes a crash on machines with a ST16C654.
On Tue, May 15, 2001 at 09:52:01AM -0400, Stuart MacDonald wrote:
> Kernel version? Distribution? Are you using a serial console?
2.4.5-pre1 (see patch).
> The revision should always be saved if it's available. Hmm.
> I didn't look carefully yesterday. The DLL always contains the
> revision for the 85x family. Why do you think it doesn't?
Because the comment was ambiguous. I don't have the data sheet for
the 85x family so I just wrote the code according to the comment.
I'll change the comment to make it clear.
> I think your patch below is good, I'm just mystified by this
> kablooey thing.
Thanks. Corrected version of the patch is below.
-VAL
--- linux-2.4.5-pre1/drivers/char/serial.c Thu Apr 19 00:26:34 2001
+++ linux/drivers/char/serial.c Thu May 17 03:12:09 2001
@@ -3507,7 +3507,7 @@
struct serial_state *state,
unsigned long flags)
{
- unsigned char scratch, scratch2, scratch3;
+ unsigned char scratch, scratch2, scratch3, scratch4;
/*
* First we check to see if it's an Oxford Semiconductor UART.
@@ -3548,20 +3548,33 @@
* then reading back DLL and DLM. If DLM reads back 0x10,
* then the UART is a XR16C850 and the DLL contains the chip
* revision. If DLM reads back 0x14, then the UART is a
-* XR16C854.
-*
+* XR16C854 and the DLL contains the chip revision.
*/
+
+ /* Save the DLL and DLM */
+
serial_outp(info, UART_LCR, UART_LCR_DLAB);
+ scratch3 = serial_inp(info, UART_DLL);
+ scratch4 = serial_inp(info, UART_DLM);
+
serial_outp(info, UART_DLL, 0);
serial_outp(info, UART_DLM, 0);
- state->revision = serial_inp(info, UART_DLL);
+ scratch2 = serial_inp(info, UART_DLL);
scratch = serial_inp(info, UART_DLM);
serial_outp(info, UART_LCR, 0);
+
if (scratch == 0x10 || scratch == 0x14) {
+ state->revision = scratch2;
state->type = PORT_16850;
return;
}
+ /* Restore the DLL and DLM */
+
+ serial_outp(info, UART_LCR, UART_LCR_DLAB);
+ serial_outp(info, UART_DLL, scratch3);
+ serial_outp(info, UART_DLM, scratch4);
+ serial_outp(info, UART_LCR, 0);
/*
* We distinguish between the '654 and the '650 by counting
* how many bytes are in the FIFO. I'm using this for now,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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
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/
"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
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/
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 )? 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
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/
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
#include
#include
#include
#include
#include
#include
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, )<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;
}
((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 )? 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/
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/
[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: IP checksum broken in 2.2 .18 ip_decrease_ttl
Fixed in the current sources, this was already fixed in 2.4.x Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 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/
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/
[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
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 > and ), 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/
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
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 and ), 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: 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
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
> > 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: 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
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/
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:[] [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 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: 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/
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/
