RE: shared memory, mmap not recommended?
> [Linus] > > > (otherwise I'll just end up disabling shared mmap - I > doubt anybody > > > really uses it anyway, but it would be more polite to just support > > > it). > > [Peter Rönnquist] > > I was thinking about using mmap for shared mememory in my program, > > but now I am reconsidering. Is the System V or Posix mechanism for > > shared memory a better(it will be supported in 2.4) choice? > > [Peter Samuelson] > Linus was talking about shared mmap on a file in an smbfs filesystem. > Rather different from what you are talking about. For regular shared > memory, shared mmap should be OK if you actually need backing store > (i.e. the state you are sharing is persistent). Often this is not the > case, in which case POSIX shm might be best. > I see, thanks a lot for the clarification. BR Peter Rönnquist - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test12-pre5
Linus Torvalds wrote: > > Ok, this contains one of the fixes for the dirty inode buffer list (the > other fix is pending, simply because I still want to understand why it > would be needed at all). Al? I've run the same test suite against vanilla test12-pre5 on two machines for five hours. On ext2/IDE/SMP+UP it's solid. I'll test Al's latest bforget_inode patch overnight, but that's already been through the wringer once. > Also, it has the final installment of the PageDirty handling, and now > officially direct IO can work by just marking the physical page dirty and > be done with it. NFS along with all filesystems have been converted, the > one hold-out still being smbfs. > > Who works on smbfs these days? I see two ways of fixing smbfs now that > "writepage()" only gets an anonymous page and no "struct file" information > any more (this also fixes the double page unlock that Andrew saw). ^^ Mike Galbraith. - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: shared memory, mmap not recommended?
[Linus] > > (otherwise I'll just end up disabling shared mmap - I doubt anybody > > really uses it anyway, but it would be more polite to just support > > it). [Peter Rönnquist] > I was thinking about using mmap for shared mememory in my program, > but now I am reconsidering. Is the System V or Posix mechanism for > shared memory a better(it will be supported in 2.4) choice? Linus was talking about shared mmap on a file in an smbfs filesystem. Rather different from what you are talking about. For regular shared memory, shared mmap should be OK if you actually need backing store (i.e. the state you are sharing is persistent). Often this is not the case, in which case POSIX shm might be best. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
shared memory, mmap not recommended?
Hello, In a recent posting Linus Torvalds mentioned (http://marc.theaimsgroup.com/?l=linux-kernel=97598683318724=2) : > (otherwise I'll just end up disabling shared mmap - I doubt anybody really uses it anyway, but it would be more polite to just support it). I was thinking about using mmap for shared mememory in my program, but now I am reconsidering. Is the System V or Posix mechanism for shared memory a better(it will be supported in 2.4) choice? (I am not subscribed to the mailing list so please CC your eventual reply) BR Peter Rönnquist Software Engineer Nokia Home Communications email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Fasttrak100 questions...
On Tue, Dec 05, 2000 at 01:07:30AM -0600, Brian F. G. Bidulock wrote: > Jeff, > > Have you also seen this applied where it is to the employer's > disadvantage? For example, given that I looked at and worked > with GPL code (say Linux kernel) in University before taking > employment as a programmer that the employer's product is > inevitably contaiminated and no longer a trade secret? Can > a previous employee get an injunction against their former > employer to cease and desist from using this negative knowledge? > > If so, I might have a solution: make the Linux kernel required > reading in University programming classes! Trade Secrets are defined by something called the Uniform Tade Secret Act, which has been adopted in most states. It calls for several points that must be met in order for something to be protected as a "trade secret". Before this act, Muna vs. Microbiological (1964) was one of the landmark cases outlining trade secret law in the US. A lot has happened since Muna, but basically, these are the points. 1. A trade secret, must of course, be a "secret". 2. Cannot be readily ascertainable to someone skilled in the art. 3. Reasonable safegards must have been taken to protect it's secrecy. 4. Must have indendent economic value. Technically, based on the premise of negative knowledge, someone could work for company A trying to build a software product, and fail at each attempt, thereby, accumulating negative knowledge. This person could then quit and go to work for Company B, build the same product, this time completing it, using previous negative knowledge gained from Company A. If Company A, had an agreement respecting trade secrets, under inevitability, Company A could claim the Company B's product was based on their IP if the employee did it within 18 months of departing Company A. This is why I think inevitability is a ridculous doctrine. It makes claim to the work experinece of employees as IP. In theory, an employee could not obtain the injunction because he would have no standing to bring a cause of action, but the copyright holder would have standing and could if he could show that the employee used negative knowledge and that he did so within a certain period of time. It's even more complicated, trade secret law makes claims that common software components arranged in new ways would qualify as a trade secret. This could also mean that any new software this person wrote would necessarily be intertwined with GPL code and trade secrets of the employer. In such a case, a Judge would "balance the equities", and would have to make a call, like telling the company to remove the GPL sections, and/or requireing the portions of the code be open sourced. He could also go the other way, and rule some sections are not covered under inevitablity. It would be a very complex case, BTW (trade secrets cases always are). :-) Jeff > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] UDF compile fix.
Hi Linus, A writepage() parameter got removed, but not the caller in the UDF filesystem, patch below fixes this. regards, Davej. -- | Dave Jones <[EMAIL PROTECTED]> http://www.suse.de/~davej | SuSE Labs diff -urN linux.vanilla/fs/udf/inode.c linux/fs/udf/inode.c --- linux.vanilla/fs/udf/inode.cTue Dec 5 01:13:22 2000 +++ linux/fs/udf/inode.cTue Dec 5 01:14:11 2000 @@ -202,7 +202,7 @@ mark_buffer_dirty(bh); udf_release_data(bh); - inode->i_data.a_ops->writepage(NULL, page); + inode->i_data.a_ops->writepage(page); UnlockPage(page); page_cache_release(page); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ymfpci.c MODULE_DEVICE_TABLE
Adam, could you check my work here? I haven't done this before It
compiles, but I don't have the hardware to verify anything. And, being
a lousy kernel hacker, I've probably introduced at least one bug.
Peter
diff -urk~ test12pre5/drivers/sound/Config.in~ test12pre5/drivers/sound/Config.in
--- test12pre5/drivers/sound/Config.in~ Mon Dec 4 23:59:44 2000
+++ test12pre5/drivers/sound/Config.in Tue Dec 5 01:02:05 2000
@@ -142,9 +142,9 @@
dep_tristate 'Yamaha FM synthesizer (YM3812/OPL-3) support'
CONFIG_SOUND_YM3812 $CONFIG_SOUND_OSS
dep_tristate 'Yamaha OPL3-SA1 audio controller' CONFIG_SOUND_OPL3SA1
$CONFIG_SOUND_OSS
dep_tristate 'Yamaha OPL3-SA2, SA3, and SAx based PnP cards'
CONFIG_SOUND_OPL3SA2 $CONFIG_SOUND_OSS
- dep_tristate 'Yamaha PCI legacy mode support' CONFIG_SOUND_YMPCI
$CONFIG_SOUND_OSS $CONFIG_PCI
+ dep_tristate 'Yamaha YMF7xx PCI audio (legacy mode)' CONFIG_SOUND_YMPCI
+$CONFIG_SOUND_OSS $CONFIG_PCI
if [ "$CONFIG_SOUND_YMPCI" = "n" ]; then
- dep_tristate 'Yamaha PCI native mode support (EXPERIMENTAL)' CONFIG_SOUND_YMFPCI
$CONFIG_SOUND_OSS
+ dep_tristate 'Yamaha YMF7xx PCI audio (native mode) (EXPERIMENTAL)'
+CONFIG_SOUND_YMFPCI $CONFIG_SOUND_OSS $CONFIG_PCI $CONFIG_EXPERIMENTAL
fi
dep_tristate '6850 UART support' CONFIG_SOUND_UART6850 $CONFIG_SOUND_OSS
diff -urk~ test12pre5/drivers/sound/ymfpci.c~ test12pre5/drivers/sound/ymfpci.c
--- test12pre5/drivers/sound/ymfpci.c~ Mon Dec 4 23:59:46 2000
+++ test12pre5/drivers/sound/ymfpci.c Tue Dec 5 00:59:44 2000
@@ -68,17 +68,19 @@
* constants
*/
-static struct ymf_devid {
- int id;
- char *name;
-} ymf_devv[] = {
- { PCI_DEVICE_ID_YAMAHA_724, "YMF724" },
- { PCI_DEVICE_ID_YAMAHA_724F, "YMF724F" },
- { PCI_DEVICE_ID_YAMAHA_740, "YMF740" },
- { PCI_DEVICE_ID_YAMAHA_740C, "YMF740C" },
- { PCI_DEVICE_ID_YAMAHA_744, "YMF744" },
- { PCI_DEVICE_ID_YAMAHA_754, "YMF754" },
+static struct pci_device_id ymf_id_tbl[] = {
+#define DEV(v, d, data) \
+ { PCI_VENDOR_ID_##v, PCI_DEVICE_ID_##v##_##d, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+(unsigned long)data }
+ DEV (YAMAHA, 724, "YMF724"),
+ DEV (YAMAHA, 724F, "YMF724F"),
+ DEV (YAMAHA, 740, "YMF740"),
+ DEV (YAMAHA, 740C, "YMF740C"),
+ DEV (YAMAHA, 744, "YMF744"),
+ DEV (YAMAHA, 754, "YMF754"),
+#undef DEV
+ { }
};
+MODULE_DEVICE_TABLE(pci, ymf_id_tbl);
/*
* Mindlessly copied from cs46xx XXX
@@ -2245,8 +2247,10 @@
return 0;
}
-static int /* __init */
-ymf_install(struct pci_dev *pcidev, int instance, int devx)
+static int ymf_instance;
+
+static int __devinit
+ymf_install_one(struct pci_dev *pcidev, const struct pci_device_id *ent)
{
ymfpci_t *codec;
@@ -2261,7 +2265,7 @@
spin_lock_init(>reg_lock);
spin_lock_init(>voice_lock);
codec->pci = pcidev;
- codec->inst = instance;
+ codec->inst = ymf_instance;
codec->irq = pcidev->irq;
codec->device_id = pcidev->device;
pci_read_config_byte(pcidev, PCI_REVISION_ID, (u8 *)>rev);
@@ -2270,8 +2274,8 @@
pci_set_master(pcidev);
/* XXX KERN_INFO */
- printk("ymfpci%d: %s at 0x%lx IRQ %d\n", instance,
- ymf_devv[devx].name, codec->reg_area_phys, codec->irq);
+ printk("ymfpci%d: %s at 0x%lx IRQ %d\n", ymf_instance,
+ (char *)ent->driver_data, codec->reg_area_phys, codec->irq);
ymfpci_aclink_reset(pcidev);
if (ymfpci_codec_ready(codec, 0, 1) < 0) {
@@ -2317,6 +2321,7 @@
codec->next = ymf_devs;
ymf_devs = codec;
+ ymf_instance++;
return 0;
}
@@ -2356,43 +2361,15 @@
MODULE_AUTHOR("Jaroslav Kysela");
MODULE_DESCRIPTION("Yamaha YMF7xx PCI Audio");
-static int /* __init */
-ymf_probe(void)
-{
- struct pci_dev *pcidev;
- int foundone;
- int i;
-
- if (!pci_present())
- return -ENODEV;
-
- /*
-* Print our proud ego-nursing "Hello, World!" message as in MS-DOS.
-*/
- /* printk(KERN_INFO "ymfpci: Yamaha YMF7xx\n"); */
-
- /*
-* Not very efficient, but Alan did it so in cs46xx.c.
-*/
- foundone = 0;
- pcidev = NULL;
- for (i = 0; i < sizeof(ymf_devv)/sizeof(ymf_devv[0]); i++) {
- while ((pcidev = pci_find_device(PCI_VENDOR_ID_YAMAHA,
- ymf_devv[i].id, pcidev)) != NULL) {
- if (ymf_install(pcidev, foundone, i) == 0) {
- foundone++;
- }
- }
- }
-
- return foundone;
-}
+static struct pci_driver ymfpci_driver = {
+ name: "ymfpci",
+ id_table: ymf_id_tbl,
+ probe: ymf_install_one,
+};
static int ymf_init_module(void)
{
- if (ymf_probe()==0)
- printk(KERN_ERR "ymfpci: No devices found.\n");
- return 0;
+
Re: Fasttrak100 questions...
Jeff, Have you also seen this applied where it is to the employer's disadvantage? For example, given that I looked at and worked with GPL code (say Linux kernel) in University before taking employment as a programmer that the employer's product is inevitably contaiminated and no longer a trade secret? Can a previous employee get an injunction against their former employer to cease and desist from using this negative knowledge? If so, I might have a solution: make the Linux kernel required reading in University programming classes! On Sat, 02 Dec 2000, Jeff V. Merkey wrote: > On Sat, Dec 02, 2000 at 10:42:29PM -0500, Theodore Y. Ts'o wrote: > >Date: Sat, 2 Dec 2000 18:21:26 -0700 > >From: "Jeff V. Merkey" <[EMAIL PROTECTED]> > > > >Under this argument, it is argued that the engineer who had source > >code access "inevitably used" negative knowledge he gained from > >his study of the Linux sources. Absent the vague descriptions of > >what a "derivative work" is in the GPL, it could be argued that > >conversion of any knowledge contained in GPL code is a "derivative > >work". > > -- Brian F. G. Bidulock¦ The reasonable man adapts himself to the ¦ [EMAIL PROTECTED]¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with Athlon CPU
On Tue, 5 Dec 2000, Lukasz Trabinski wrote: >Date: Tue, 5 Dec 2000 02:19:55 +0100 (CET) >From: Lukasz Trabinski <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Cc: [EMAIL PROTECTED] >Content-Type: TEXT/PLAIN; charset=ISO-8859-2 >Subject: Problems with Athlon CPU > >Hello > >There is probably not a kernel bug, but bug in gcc, but... :) It is a kernel bug. [SNIP] >gcc version 2.96 2731 (Red Hat Linux 7.0) You can't build a kernel with that compiler. You _must_ use gcc 2.91.66 or another compiler that can compile the kernel. Red Hat ships gcc 2.91.66 packaged as "kgcc" for kernel builds as do other major vendors. You must edit the top level makefile appropriately first before building. >[lukasz@beer lukasz]$ rpm -q glibc >glibc-2.2-5 The kernel doesn't use any libc so it doesn't matter. >Any sugestions? On others machines with AMD-K6 or Petnium-III/II and >with the same version of glibc and gcc that problems does not exists! No, you must have a different gcc on the other machines. You can't build a kernel with gcc 2.96 as the kernel is buggy. -- Mike A. Harris - Linux advocate - Open source advocate This message is copyright 2000, all rights reserved. Views expressed are my own, not necessarily shared by my employer. -- If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one? -- Tom Cargill, C++ Journal, Fall 1990. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Assistance requested in demystifying wait queues.
Hello,
I'm absolutely green when it comes to Linux kernel development, and so
working on a school project to port a TCP/IP-based service into the kernel
has been quite challenging (but also intesting)! Currently, I'm absolutely
mystified regarding how the "wait queue" subsystem works. I've been
reading the code, and usually that combined with an example is enough,
but not this time.
I searched the linux-kernel archives, and found a message from Mr. Timur
Tabi ([EMAIL PROTECTED]). In October, he asked for an explanation of
'wait_queue_head_t' vs. 'wait_queue_t'. I'm confused on this (as well as
several other points), but unfortunately, I didn't see any response to Mr.
Tabi. So, I thought I'd try fashioning my own message.
The kHTTPd source is in many ways similar to what we are trying to
accomplish. Basically, we are trying to implement select() in the kernel
-- we have a bunch of sockets, and we want to return when one of them has
data. We have code that performs all of the necessary checks, but the
whole "going to sleep until data arrives" aspect is the stumper.
I have managed to draw the following skeleton from the kHTTPd source
(main.c):
wait_queue_head_t dummyWQ;
init_waitqueue_head ();
DECLARE_WAITQUEUE (local_wait);
add_wait_queue_exclusive (socket->sk->sleep, _wait);
set_current_state (TASK_INTERRUPTIBLE|TASK_EXCLUSIVE);
while (we don't need to stop) {
if nothing on socket
interruptible_sleep_on_timeout (, timeout);
else
handle socket data
}
remove_wait_queue (sock->sk->sleep, _wait);
>From the structure of the kHTTPd code, it appears as if the call to
'interruptible_sleep_on_timeout()' will return when either data arrives on
one of the sockets that kHTTPd controls, or if the timeout transpires.
However, I cannot see how this can be so. It appears as if the 'dummyWQ'
and 'local_wait' queue are entirely *separate*. I can see how the socket
is tied to the 'local_wait' (via add_wait_queue_exclusive()), but I do not
comprehend how 'interruptible_sleep_on_timeout() knows anything about any
sockets.
Any assistance that could be provided (explaining the wait_queue function
calls, a pointer to some documentation, etc.) would be *sincerely*
appreciated. Please CC: all responses to me directly, since I am not
subscribed to the list.
TIA,
--Andy Reitz.
--
Andy Reitz <[EMAIL PROTECTED]> (217) 244-3862
Research Assistant, CCSO http://www.uiuc.edu/ph/www/areitz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Running linux from flash
Hi, Could anyone point me to information on running linux from flash? Rgds, Sreekrishnan V - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[RFC-2] Configuring Synchronous Interfaces in Linux
Hello, Thanks to all of you who responded to my first RFC on this subject. The discussion ended up going in the Ethernet direction, and I frankly don't know whether that applies to this case, or even if it _should_ apply or they should really be separate config. subsystems. This is another thing that you may wanna throw your opinions on. Anyhow, the parameters we currently need to configure on our board (the PC300) are as follows: - Media: V.35, RS-232, X.21, T1, E1 - Protocol: Frame Relay, (Cisco)-HDLC, PPP, X.25 (not sure whether that is already supported by the 'hw' option) - Clock: 'ext' (or 0, which implies external clock) or some numeric value > 0 (which implies internal clock); setting it to 'int' would set it to some fixed numeric value > 0 (useful for T1/E1 links, just to indicate master clock as opposed to slave or 'ext' clock) - Frame Relay only: - End type: DCE or DTE (maybe this applies to other interface types as well) - DLCI: DLC number for the interface - T1/E1 only: - Line code: - Frame mode: - LBO (T1 only): line-build-out - Rx Sensitivity: short-haul or long-haul - Active channels: mask that represents the possible 24/32 channels (timeslots) on a T1/E1 line I'm sure that _all_ the other sync cards need to configure the _same_ parameters (or a subset of them), and there may be cards that need even more parameters (but we have to start somewhere ... ;). So having a unified interface and making the drivers compliant to it is not that hard and surely would help users to dump the currently ridiculous set of individual config. tools for these cards (yes, we currently have our own pc300cfg, along with the -- not absolute -- "standard" sethdlc utility). I'm willing to go for this implementation, but I wanted to know first: - whether ifconfig is the right place to do it; - where I should create the new ioctl's to handle these new parameters. Suggestions / comments are more than welcome. Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test12-pre5
The following fixes to many arguments error in fs/udf/inode.c for test12-pre5 --- fs/udf/inode.c.orig Mon Dec 4 23:34:23 2000 +++ fs/udf/inode.c Tue Dec 5 00:26:59 2000 @@ -202,7 +202,7 @@ mark_buffer_dirty(bh); udf_release_data(bh); - inode->i_data.a_ops->writepage(NULL, page); + inode->i_data.a_ops->writepage(page); UnlockPage(page); page_cache_release(page); -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test12-pre4 drivers/net/dummy
Alan has it and Linus hasn't applied Alan's patch yet... Linus said. "[ Alan - I ahve your patches in my incoming queue still, I wanted to get an interim version out to check with Al on the block list and the VM stuff with Rik and people. ]" "Garst R. Reese" wrote: > > Did you send it Linus? > It is not in pre5 > Garst -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Kernel 2.4-test12-pre4 BUG - scsi (?)
[1.] One line summary of the problem: During burning of CD onto SCSI driver (using cdrecord) crashes. during the burn (10% or so) it crashes with "Unable to handle kernel null pointer" [2.] Full description of the problem/report: During burning of CD onto SCSI driver (using cdrecord) crashes. during the burn (10% or so) it crashes with "Unable to handle kernel null pointer" and dumps a whole lot of things to the screen (flags of some sort, eg "eax=..") [3.] Keywords (i.e., modules, networking, kernel): scsi, cd record, null pointer [4.] Kernel version (from /proc/version): Linux version 2.4.0-test12 (root@crazney) (gcc version 2.95.3 19991030 (prerelease)) #5 Tue Dec 5 10:55:46 EST 2000 [7.] Environment console?? [7.1.] Software (add the output of the ver_linux script here) Cdrecord 1.8.1 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling $ sh ver_linux -- Versions installed: (if some fields are empty or look -- unusual then possibly you have very old versions) Linux crazney 2.4.0-test12 #5 Tue Dec 5 10:55:46 EST 2000 i686 unknown Kernel modules 2.3.17 Gnu C 2.95.3 Gnu Make 3.79 Binutils 2.9.5.0.31 Linux C Library2.1.3 Dynamic linker ldd (GNU libc) 2.1.3 Procps 2.0.6 Mount 2.10h Net-tools 1.55 Console-tools 0.2.3 Sh-utils 2.0 Modules Loaded NVdriver 8139too emu10k1 [7.2.] Processor information (from /proc/cpuinfo): $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 3 cpu MHz : 701.606 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 3 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1399.19 [7.3.] Module information (from /proc/modules): $ cat /proc/modules NVdriver 530416 17 (autoclean) 8139too15296 1 (autoclean) emu10k142960 0 [7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem) $ cat /proc/ioports -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 0376-0376 : ide1 03c0-03df : vga+ 03f6-03f6 : ide0 0cf8-0cff : PCI conf1 4000-403f : Intel Corporation 82371AB PIIX4 ACPI 5000-501f : Intel Corporation 82371AB PIIX4 ACPI c000-c01f : Intel Corporation 82371AB PIIX4 USB c400-c4ff : Symbios Logic Inc. (formerly NCR) 53c810 c400-c47f : ncr53c8xx c800-c81f : Creative Labs SB Live! EMU1 c800-c81f : EMU10K1 cc00-cc07 : Creative Labs SB Live! d000-d0ff : Accton Technology Corporation SMC2-1211TX d000-d0ff : eth0 d400-d407 : Triones Technologies, Inc. HPT366 d400-d407 : ide2 d800-d803 : Triones Technologies, Inc. HPT366 d802-d802 : ide2 dc00-dcff : Triones Technologies, Inc. HPT366 dc00-dc07 : ide2 dc10-dcff : HPT366 e000-e007 : Triones Technologies, Inc. HPT366 (#2) e400-e403 : Triones Technologies, Inc. HPT366 (#2) e800-e8ff : Triones Technologies, Inc. HPT366 (#2) e800-e807 : ide3 e810-e8ff : HPT366 f000-f00f : Intel Corporation 82371AB PIIX4 IDE f000-f007 : ide0 f008-f00f : ide1 $ cat /proc/iomem -0009efff : System RAM 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000d-000d17ff : Extension ROM 000f-000f : System ROM 0010-09ff : System RAM 0010-00257e2f : Kernel code 00257e30-0026cee3 : Kernel data d800-dfff : PCI Bus #01 d800-dfff : nVidia Corporation NV15 (Geforce2 GTS) e000-e3ff : Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge e400-e7ff : S3 Inc. ViRGE/DX or /GX e800-e9ff : PCI Bus #01 e800-e8ff : nVidia Corporation NV15 (Geforce2 GTS) ec00-ecff : Accton Technology Corporation SMC2-1211TX ec00-ecff : eth0 ec001000-ec0010ff : Symbios Logic Inc.
Re: test12-pre5
On Mon, 4 Dec 2000, Linus Torvalds wrote: > So? Why wouldn't clear_inode() get rid of it? It will. Mea culpa. However, other reasons for taking the bh of freed block from the list still stand. IOW, consider that part as an optimization. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test12-pre4 drivers/net/dummy
Did you send it Linus? It is not in pre5 Garst "Mohammad A. Haque" wrote: > Ok, so here's the proper patch for those who dont want to wait for t5 =) > Ignore previous. > > On Mon, 4 Dec 2000, Jeff Garzik wrote: > > > the fix is in module.h which needs extra parens in the def of > > set_module_owner... > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] inode dirty blocks
On Mon, 4 Dec 2000, Linus Torvalds wrote:
> I just wanted to be clear on the purpose of the patches. The bforget() one
> looks like "taking care of the details", but not like a bug-fix. Agreed?
Agreed - invalidate_inode_buffers() seems to be doing the right thing,
so previous objections do not apply.
> > We can survive without them (modulo patch to clear_inode()), but...
>
> The "patch to clean-inode" is the one I already did from sct? Or are we
> talking about another issue?
No, the same one. I missed the invalidate_inode_buffers() bit.
> > BTW, there is another reason why we want to have separate function
> > for freeing the stuff: we may want to mark them clean. If they are
> > already under IO it will do nothing, but if they are merely dirty...
>
> Yes. Make it so. In the meantime, does everybody agree that pre5 fixes the
> bugs, even though it still has these discussion items left?
With respect to dirty blocks - hopefully yes.
Cheers,
Al
PS: bforget patch (with mark_buffer_clean() added) follows. And yes, it's
optimization and not a bug-fix.
diff -urN rc12-pre5/fs/buffer.c rc12-pre5-dirty_blocks/fs/buffer.c
--- rc12-pre5/fs/buffer.c Tue Dec 5 02:03:14 2000
+++ rc12-pre5-dirty_blocks/fs/buffer.c Tue Dec 5 02:40:16 2000
@@ -1164,6 +1164,32 @@
}
/*
+ * Call it when you are going to free the block. The difference between
+ * that and bforget() is that we remove the thing from inode queue
+ * unconditionally and mark it clean.
+ */
+void bforget_inode(struct buffer_head * buf)
+{
+ mark_buffer_clean(buf);
+ /* grab the lru lock here to block bdflush. */
+ spin_lock(_list_lock);
+ write_lock(_table_lock);
+ remove_inode_queue(buf);
+ if (!atomic_dec_and_test(>b_count) || buffer_locked(buf))
+ goto in_use;
+ __hash_unlink(buf);
+ write_unlock(_table_lock);
+ __remove_from_lru_list(buf, buf->b_list);
+ spin_unlock(_list_lock);
+ put_last_free(buf);
+ return;
+
+ in_use:
+ write_unlock(_table_lock);
+ spin_unlock(_list_lock);
+}
+
+/*
* bread() reads a specified block and returns the buffer that contains
* it. It returns NULL if the block was unreadable.
*/
@@ -1460,6 +1486,9 @@
clear_bit(BH_Mapped, >b_state);
clear_bit(BH_Req, >b_state);
clear_bit(BH_New, >b_state);
+ spin_lock(_list_lock);
+ remove_inode_queue(bh);
+ spin_unlock(_list_lock);
}
}
diff -urN rc12-pre5/fs/ext2/inode.c rc12-pre5-dirty_blocks/fs/ext2/inode.c
--- rc12-pre5/fs/ext2/inode.c Tue Dec 5 02:03:14 2000
+++ rc12-pre5-dirty_blocks/fs/ext2/inode.c Tue Dec 5 02:37:59 2000
@@ -416,7 +416,7 @@
/* Allocation failed, free what we already allocated */
for (i = 1; i < n; i++)
- bforget(branch[i].bh);
+ bforget_inode(branch[i].bh);
for (i = 0; i < n; i++)
ext2_free_blocks(inode, le32_to_cpu(branch[i].key), 1);
return err;
@@ -484,7 +484,7 @@
changed:
for (i = 1; i < num; i++)
- bforget(where[i].bh);
+ bforget_inode(where[i].bh);
for (i = 0; i < num; i++)
ext2_free_blocks(inode, le32_to_cpu(where[i].key), 1);
return -EAGAIN;
@@ -854,7 +854,7 @@
(u32*)bh->b_data,
(u32*)bh->b_data + addr_per_block,
depth);
- bforget(bh);
+ bforget_inode(bh);
/* Writer: ->i_blocks */
inode->i_blocks -= inode->i_sb->s_blocksize / 512;
/* Writer: end */
diff -urN rc12-pre5/include/linux/fs.h rc12-pre5-dirty_blocks/include/linux/fs.h
--- rc12-pre5/include/linux/fs.hTue Dec 5 02:03:19 2000
+++ rc12-pre5-dirty_blocks/include/linux/fs.h Tue Dec 5 02:37:59 2000
@@ -1201,6 +1201,7 @@
__brelse(buf);
}
extern void __bforget(struct buffer_head *);
+extern void bforget_inode(struct buffer_head *);
static inline void bforget(struct buffer_head *buf)
{
if (buf)
diff -urN rc12-pre5/kernel/ksyms.c rc12-pre5-dirty_blocks/kernel/ksyms.c
--- rc12-pre5/kernel/ksyms.cTue Dec 5 02:03:20 2000
+++ rc12-pre5-dirty_blocks/kernel/ksyms.c Tue Dec 5 02:38:00 2000
@@ -188,6 +188,7 @@
EXPORT_SYMBOL(breada);
EXPORT_SYMBOL(__brelse);
EXPORT_SYMBOL(__bforget);
+EXPORT_SYMBOL(bforget_inode);
EXPORT_SYMBOL(ll_rw_block);
EXPORT_SYMBOL(__wait_on_buffer);
EXPORT_SYMBOL(___wait_on_page);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] inode dirty blocks
[Mohammad A. Haque] > Cool. Anyone have have a unified patch against pre4 or should I start > digging through my mail? =) test12pre5, I guess. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Fasttrak100 questions...
[Pavel Machek] > Hmm, add special code for GPL into gzip ;-). Someone on debian-devel thought of this, but went one further: change the gzip header magic so that only a "GPL-enabled" gzip can decompress it. I wonder how the zlib maintainers (zlib is not GPL) would feel about having to add support for *that*. (: > PS: That's crazy. Including it by reference should be enough. I do > not want waste 17K on every file. It's not crazy, it's RMS. (: I guess he is worried about some .deb file falling into the wrong hands and being used on a system where nobody has heard of the GPL and there is no copy available ... then the target user won't know his or her rights and responsibilities. Yeah, I think it's pretty far-fetched too. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test12-pre5
On Mon, 4 Dec 2000, Alexander Viro wrote:
>
> On Mon, 4 Dec 2000, Linus Torvalds wrote:
> >
> > Ok, this contains one of the fixes for the dirty inode buffer list (the
> > other fix is pending, simply because I still want to understand why it
> > would be needed at all). Al?
>
> See previous posting. BTW, -pre5 doesn't do the right thing in clear_inode().
>
> Scenario: bh of indirect block is busy (whatever reason, flush_dirty_buffers(),
> anything that can bump ->b_count for a while). ext2_truncate() frees the
> thing and does bforget(). bh is left on the inode's list. Woops...
So? Why wouldn't clear_inode() get rid of it?
> The minimal fix would be to make clear_inode() empty the list. IMO it's
> worse than preventing the freed stuff from being on that list...
This _is_ what clear_inode() does in pre5 (and in pre4, for that matter):
void clear_inode(struct inode *inode)
{
if (!list_empty(>i_dirty_buffers))
invalidate_inode_buffers(inode);
...
which I find perfectly readable. And should mean that no dirty buffers
should be associated with the inode any more. ext2 calls clear_inode()
from ext2_free_inode(), and as far as I can tell the only thing that can
happen after that is that the inode is still scheduled for write-out
(which explains how the bug you fixed would cause a dirty block to be
attached to the inode _after_ we did a clear_inode() on it).
Or are you thinking of something else?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
dmfe patch
Hello,
The following patch is a combo patch between a revised locking patch
and a transmission patch for drivers/net/dmfe . Please review this before
it goes to Linus for a final blessing. Please apply to
2.4.0-test12-pre5 . [For some reason, my juno account
truncates the following, but my CMU account doesn't.]
Regards,
Frank
--- drivers/net/dmfe.c.org Sat Dec 2 15:50:28 2000
+++ drivers/net/dmfe.c Sat Dec 2 17:02:03 2000
@@ -57,6 +57,13 @@
Resource usage cleanups.
Report driver version to user.
+ Tobias Ringstrm <[EMAIL PROTECTED]> :
+ Rewrote the transmit code to actually use the ring buffer,
+ and to generate a lot fewer interrupts.
+
+ Frank Davis <[EMAIL PROTECTED]>
+ Added SMP-safe locking mechanisms
+
TODO
Implement pci_driver::suspend() and pci_driver::resume()
@@ -68,7 +75,7 @@
*/
-#define DMFE_VERSION "1.30 (June 11, 2000)"
+#define DMFE_VERSION "1.30p2 (November 30, 2000)"
#include
@@ -88,6 +95,7 @@
#include
#include
#include
+#include
#include
#include
@@ -108,6 +116,7 @@
#define TX_MAX_SEND_CNT 0x1/* Maximum tx packet per time */
#define TX_DESC_CNT 0x10 /* Allocated Tx descriptors */
#define RX_DESC_CNT 0x10 /* Allocated Rx descriptors */
+#define TX_IRQ_THR 12
#define DESC_ALL_CNTTX_DESC_CNT+RX_DESC_CNT
#define TX_BUF_ALLOC0x600
#define RX_ALLOC_SIZE 0x620
@@ -178,7 +187,7 @@
u32 chip_id;/* Chip vendor/Device ID */
u32 chip_revision; /* Chip revision */
struct net_device *next_dev;/* next device */
-
+ spinlock_t lock; /* Spinlock */
struct pci_dev *net_dev;/* PCI device */
unsigned long ioaddr; /* I/O base address */
@@ -198,8 +207,7 @@
struct rx_desc *first_rx_desc;
struct rx_desc *rx_insert_ptr;
struct rx_desc *rx_ready_ptr; /* packet come pointer */
- u32 tx_packet_cnt; /* transmitted packet count */
- u32 tx_queue_cnt; /* wait to send packet count */
+ u32 tx_live_cnt;/* number of used/live tx slots */
u32 rx_avail_cnt; /* available rx descriptor count */
u32 interval_rx_cnt;/* rx packet count a callback time */
@@ -423,9 +431,17 @@
for (i = 0; i < 64; i++)
((u16 *) db->srom)[i] = read_srom_word(pci_iobase, i);
+ printk(KERN_INFO "%s: Davicom DM%04lx at 0x%lx,",
+ dev->name,
+ ent->driver_data >> 16,
+ pci_iobase);
+
/* Set Node address */
- for (i = 0; i < 6; i++)
+ for (i = 0; i < 6; i++) {
dev->dev_addr[i] = db->srom[20 + i];
+ printk("%c%02x", i ? ':' : ' ', dev->dev_addr[i]);
+ }
+ printk(", IRQ %d\n", pci_irqline);
return 0;
@@ -490,8 +506,6 @@
/* system variable init */
db->cr6_data = CR6_DEFAULT | dmfe_cr6_user_set;
- db->tx_packet_cnt = 0;
- db->tx_queue_cnt = 0;
db->rx_avail_cnt = 0;
db->link_failed = 0;
db->wait_reset = 0;
@@ -536,10 +550,12 @@
{
struct dmfe_board_info *db = dev->priv;
u32 ioaddr = db->ioaddr;
-
+ unsigned long flags;
+
DMFE_DBUG(0, "dmfe_init_dm910x()", 0);
/* Reset DM910x board : need 32 PCI clock to complete */
+ spin_lock_irqsave(>lock,flags);
outl(DM910X_RESET, ioaddr + DCR0); /* RESET MAC */
DELAY_5US;
outl(db->cr0_data, ioaddr + DCR0);
@@ -547,6 +563,7 @@
outl(0x180, ioaddr + DCR12);/* Let bit 7 output port */
outl(0x80, ioaddr + DCR12); /* RESET DM9102 phyxcer */
outl(0x0, ioaddr + DCR12); /* Clear RESET signal */
+ spin_unlock_irqrestore(>lock,flags);
/* Phy addr : DM910(A)2/DM9132/9801, phy address = 1 */
db->phy_addr = 1;
@@ -595,46 +612,38 @@
{
struct dmfe_board_info *db = dev->priv;
struct tx_desc *txptr;
+ static unsigned pkt_num = TX_IRQ_THR;
DMFE_DBUG(0, "dmfe_start_xmit", 0);
-
- netif_stop_queue(dev);
-
- /* Too large packet check */
- if (skb->len > MAX_PACKET_SIZE) {
- printk(KERN_ERR "%s: oversized frame (%d bytes) for
transmit.\n", dev->name, (u16) skb->len);
- dev_kfree_skb(skb);
- return 0;
- }
- /* No Tx resource check, it never happen nromally */
- if (db->tx_packet_cnt >= TX_FREE_DESC_CNT) {
- return 1;
- }
/* transmit this packet */
txptr = db->tx_insert_ptr;
memcpy((char *) txptr->tx_buf_ptr, (char *) skb->data, skb->len);
- txptr->tdes1 = 0xe100 | skb->len;
+ if (--pkt_num == 0)
+ {
+ txptr->tdes1 = 0xe100 | skb->len;
+ pkt_num = TX_IRQ_THR;
+ }
+ else
+ txptr->tdes1 = 0x6100 | skb->len;
+
+ /* Transmit Packet Process */
+ txptr->tdes0 = 0x8000;
Re: [PATCH] inode dirty blocks
On Mon, 4 Dec 2000, Alexander Viro wrote: > > Well, to start with you don't want random bh's floating around on the > inode's list. With the current code truncate()+fsync() can send a lot > of already freed stuff to disk. Even though we can survive that (making > clear_inode() to get rid of the list will save you from corruption)... > it doesn't look like a good idea. Now, I'll agree with that, certainly. I just wanted to be clear on the purpose of the patches. The bforget() one looks like "taking care of the details", but not like a bug-fix. Agreed? (Which is not to say I won't apply it - I just want to make sure we have the issues under control). > BTW, in the current form clear_inode() doesn't get rid of the dirty > buffers. It misses the pages that became anonymous and it misses the > metadata that became freed. We can do that, but I'ld rather avoid > leaving these buffer_heads on the inode's list - stuff that got freed > has no business to be accessible from in-core inode. Again, I agree with you, but it looks like that is a cleanup issue rather than a bug. > > I think that the second patch from Al (the inode dirty meta-data) is the > > _real_ fix, and I don't see why the bforget changes should matter. > > We can survive without them (modulo patch to clear_inode()), but... The "patch to clean-inode" is the one I already did from sct? Or are we talking about another issue? > BTW, there is another reason why we want to have separate function > for freeing the stuff: we may want to mark them clean. If they are > already under IO it will do nothing, but if they are merely dirty... Yes. Make it so. In the meantime, does everybody agree that pre5 fixes the bugs, even though it still has these discussion items left? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test12-pre5
On Mon, 4 Dec 2000, Linus Torvalds wrote: > > Ok, this contains one of the fixes for the dirty inode buffer list (the > other fix is pending, simply because I still want to understand why it > would be needed at all). Al? See previous posting. BTW, -pre5 doesn't do the right thing in clear_inode(). Scenario: bh of indirect block is busy (whatever reason, flush_dirty_buffers(), anything that can bump ->b_count for a while). ext2_truncate() frees the thing and does bforget(). bh is left on the inode's list. Woops... The minimal fix would be to make clear_inode() empty the list. IMO it's worse than preventing the freed stuff from being on that list... Comments? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test12-pre5: drivers/net/dummy.c compile error
Hello, The drivers/net/dummy.c compile error still exists..Looks like the module.h patch wasn't included. Regards, Frank - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] inode dirty blocks
On Mon, 4 Dec 2000, Linus Torvalds wrote: > > > On Tue, 5 Dec 2000, Andrew Morton wrote: > > > > - test12-pre4 > > - aviro bforget patch > > Is the bforget patch really needed? > > If clear_inode() gets rid of dirty buffers, I don't see how new dirty > buffers can magically appear. I may have missed part of the discussion on > all this. Well, to start with you don't want random bh's floating around on the inode's list. With the current code truncate()+fsync() can send a lot of already freed stuff to disk. Even though we can survive that (making clear_inode() to get rid of the list will save you from corruption)... it doesn't look like a good idea. BTW, in the current form clear_inode() doesn't get rid of the dirty buffers. It misses the pages that became anonymous and it misses the metadata that became freed. We can do that, but I'ld rather avoid leaving these buffer_heads on the inode's list - stuff that got freed has no business to be accessible from in-core inode. > I think that the second patch from Al (the inode dirty meta-data) is the > _real_ fix, and I don't see why the bforget changes should matter. We can survive without them (modulo patch to clear_inode()), but... BTW, there is another reason why we want to have separate function for freeing the stuff: we may want to mark them clean. If they are already under IO it will do nothing, but if they are merely dirty... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test12-pre5
Ok, this contains one of the fixes for the dirty inode buffer list (the other fix is pending, simply because I still want to understand why it would be needed at all). Al? Also, it has the final installment of the PageDirty handling, and now officially direct IO can work by just marking the physical page dirty and be done with it. NFS along with all filesystems have been converted, the one hold-out still being smbfs. Who works on smbfs these days? I see two ways of fixing smbfs now that "writepage()" only gets an anonymous page and no "struct file" information any more (this also fixes the double page unlock that Andrew saw). - disable shared mmap over smbfs (very easily done by just setting writepage to NULL) - fetch the dentry that writepage needs by just looking at the inode->i_dentry list and/or just make the smbfs page cache host be the dentry instead of the inode like other filesystems. The first approach assumes that all paths are equal for writeout, the second one assumes that there are no hard linking going on in smbfs. Somebody more knowledgeable than I will have to make the decision (otherwise I'll just end up disabling shared mmap - I doubt anybody really uses it anyway, but it would be more polite to just support it). NOTE! There's another change to "writepage()" semantics than just dropping the "struct file": the new writepage() is supposed to mirror the logic of readpage(), and unlock the page when it is done with it. This allows the VM system more visibility into what IO is pending (which the VM doesn't take advantage of yet, but now it can _truly_ use the same logic for both swapout and for dirty file writeback). The other change is that I forward-ported the ymfpci driver from 2.2.18, as it works better than the ALSA one on my now-to-be-main-laptop ;) [ Alan - I ahve your patches in my incoming queue still, I wanted to get an interim version out to check with Al on the block list and the VM stuff with Rik and people. ] Linus - pre5: - Jaroslav Kysela: ymfpci driver - me: get rid of bogus MS_INVALIDATE semantics - me: final part of the PageDirty() saga - Rusty Russell: 4-way SMP iptables fix - Al Viro: oops - bad ext2 inode dirty block bug - pre4: - Andries Brouwer: final isofs pieces. - Kai Germaschewski: ISDN - play CD audio correctly, don't stop after 12 minutes. - Anton Altaparmakov: disable NTFS mmap for now, as it doesn't work. - Stephen Tweedie: fix inode dirty block handling - Bill Hartner: reschedule_idle - prefer right cpu - Johannes Erdfelt: USB updates - Alan Cox: synchronize - Richard Henderson: alpha updates and optimizations - Geert Uytterhoeven: fbdev could be fooled into crashing fix - Trond Myklebust: NFS filehandles in inode rather than dentry - pre3: - me: more PageDirty / swapcache handling - Neil Brown: raid and md init fixes - David Brownell: pci hotplug sanitization. - Kanoj Sarcar: mips64 update - Kai Germaschewski: ISDN sync - Andreas Bombe: ieee1394 cleanups and fixes - Johannes Erdfelt: USB update - David Miller: Sparc and net update - Trond Myklebust: RPC layer SMP fixes - Thomas Sailer: mixed sound driver fixes - Tigran Aivazian: use atomic_dec_and_lock() for free_uid() - pre2: - Peter Anvin: more P4 configuration parsing - Stephen Tweedie: O_SYNC patches. Make O_SYNC/fsync/fdatasync do the right thing. - Keith Owens: make mdule loading use the right struct module size - Boszormenyi Zoltan: get MTRR's right for the >32-bit case - Alan Cox: various random documentation etc - Dario Ballabio: EATA and u14-34f update - Ivan Kokshaysky: unbreak alpha ruffian - Richard Henderson: PCI bridge initialization on alpha - Zach Brown: correct locking in Maestro driver - Geert Uytterhoeven: more m68k updates - Andrey Savochkin: eepro100 update - Dag Brattli: irda update - Johannes Erdfelt: USB update - pre1: (for ISDN synchronization _ONLY_! Not complete!) - Byron Stanoszek: correct decimal precision for CPU MHz in /proc/cpuinfo - Ollie Lho: SiS pirq routing. - Andries Brouwer: isofs cleanups - Matt Kraai: /proc read() on directories should return EISDIR, not EINVAL - me: be stricter about what we accept as a PCI bridge setup. - me: always set PCI interrupts to be level-triggered when we enable them. - me: updated PageDirty and swap cache handling - Peter Anvin: update A20 code to work without keyboard controller - Kai Germaschewski: ISDN updates - Russell King: ARM updates - Geert Uytterhoeven: m68k updates - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] inode dirty blocks
Cool. Anyone have have a unified patch against pre4 or should I start
digging through my mail? =)
Andrew Morton wrote:
> This is with
>
> - test12-pre4
> - aviro bforget patch
> - UnlockPage() removed from vmscan.c:623
> - and
>
> --- linux-2.4.0-test12-pre4/fs/ext2/inode.c Mon Dec 4 21:07:12 2000
> +++ linux-akpm/fs/ext2/inode.c Tue Dec 5 08:46:38 2000
> @@ -1208,7 +1208,7 @@
> raw_inode->i_block[0] = cpu_to_le32(kdev_t_to_nr(inode->i_rdev));
> else for (block = 0; block < EXT2_N_BLOCKS; block++)
> raw_inode->i_block[block] = inode->u.ext2_i.i_data[block];
> - mark_buffer_dirty_inode(bh, inode);
> + mark_buffer_dirty(bh);
> if (do_sync) {
> ll_rw_block (WRITE, 1, );
> wait_on_buffer (bh);
--
=
Mohammad A. Haque http://www.haque.net/
[EMAIL PROTECTED]
"Alcohol and calculus don't mix. Project Lead
Don't drink and derive." --Unknown http://wm.themes.org/
[EMAIL PROTECTED]
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] inode dirty blocks
On Tue, 5 Dec 2000, Andrew Morton wrote: > > - test12-pre4 > - aviro bforget patch Is the bforget patch really needed? If clear_inode() gets rid of dirty buffers, I don't see how new dirty buffers can magically appear. I may have missed part of the discussion on all this. I think that the second patch from Al (the inode dirty meta-data) is the _real_ fix, and I don't see why the bforget changes should matter. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[OT] util-linux-2.10r released
Now that there was some discussion about umount, I released a version of mount/umount that perhaps has a slightly better behaviour. Since the change was largish (and is untested), don't put it blindly into your distribution. Another change was one intended to make things behave a bit better for Japanese (with variable width characters). Since I changed the patch a bit, it is quite possible I broke things both for Japanese and English. Andries - [EMAIL PROTECTED] ftp://ftp.win.tue.nl/pub/linux-local/utils/util-linux/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test12-pre4 boot failure (better than pre3 and lower)
On Mon, 4 Dec 2000 20:39:29 -0500, Wakko Warner <[EMAIL PROTECTED]> wrote: >Keith Owens wrote >> Is there any chance of changing arch/alpha/kernel/traps.c to print >> registers, trace and _raw_ code, in that order so it is more like other >> architectures? You can print the decoded instructions as well (prefix >> Decode:, not Code:) as long as the raw code bytes are also available. >> >> In the meantime, this patch to ksymoops 2.3.5 will pick up the change >> to the trace lines. It will still complain about a bad code line, >> ksymoops is built for raw data. > >Didn't help much: >Code: 40203001 addl t0,1,t0 >Warning (Oops_code): trailing garbage ignored on Code: line > Text: 'Code: 40203001 addl t0,1,t0' >Trace:323658 323600 Because the trace is printed after the code line, it is treated as part of the next oops, confusing. Even more of a problem, the trace addresses only print the low word of the address, that should really be Trace: fc323658 fc323600 If somebody would change the Alpha oops text to print the registers, the trace (with full addresses) and original code, in that order, then ksymoops would have no problem. I do not want to change ksymoops because that might affect processing of logs for other architectures. IMNSHO we need to be more consistent in the way that we print oops logs, Alpha is quite different from the other architectures. In the meantime, if you manually edit the oops log to this layout then you will get a much better listing. Unable to handle kernel paging request at virtual address 0010 swapper(53): Oops 0 pc = [] ra = [] ps = Using defaults from ksymoops -t elf64-alpha -a alpha v0 = t0 = 0012 t1 = fc485748 t2 = fc0009f5c560 t3 = fc46cfb0 t4 = t5 = fffe t6 = t7 = fc0009e0 s0 = fc323600 s1 = s2 = fc0009f5c560 s3 = fc0009f5c560 s4 = fc0009eb0ac0 s5 = fc0009eb0ac0 s6 = fc0009eb0ac0 a0 = fc4870c8 a1 = fc0009e00050 a2 = fc4871c8 a3 = a4 = 0001 a5 = t8 = 0001 t9 = 0003 t10= 0004 t11= 0010 pv = fc323600 at = gp = fc4a3f58 sp = fc0009dffee0 Trace: fc323658 fc323600 Code: 40203001 b82b e42001fe b57e0148 a5480428 a0220008 a52a0028 That last line may be incomplete, it is probably missing the failing instruction. To build a correct Code: line, extract the hex values for the code bytes, enclose the failing instruction in < >, without the leading '*'. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] inode dirty blocks
Alexander Viro wrote:
>
> OK, guys, I think I've got it:
Yes, you have.
Two machines, four hours, zero failures.
This is with
- test12-pre4
- aviro bforget patch
- UnlockPage() removed from vmscan.c:623
- and
--- linux-2.4.0-test12-pre4/fs/ext2/inode.c Mon Dec 4 21:07:12 2000
+++ linux-akpm/fs/ext2/inode.c Tue Dec 5 08:46:38 2000
@@ -1208,7 +1208,7 @@
raw_inode->i_block[0] = cpu_to_le32(kdev_t_to_nr(inode->i_rdev));
else for (block = 0; block < EXT2_N_BLOCKS; block++)
raw_inode->i_block[block] = inode->u.ext2_i.i_data[block];
- mark_buffer_dirty_inode(bh, inode);
+ mark_buffer_dirty(bh);
if (do_sync) {
ll_rw_block (WRITE, 1, );
wait_on_buffer (bh);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test11: kernel: waitpid(823) failed, -512
[EMAIL PROTECTED] wrote:
>
> On Sun, Dec 03, 2000 at 11:36:11PM +0100, Frank van Maarseveen wrote:
> > While playing with routing (zebra) and PPP I regularly see this
> > message appearing. It always happens when pppd terminates a connection,
> > e.g:
> > Dec 3 23:09:08 mimas kernel: waitpid(823) failed, -512
>
> This means a system call returned with an error code of -ERESTARTSYS
> when a signal wasn't pending; this is a kernel bug.
>
> However, I've looked at the code to sys_wait4 (which implements
> waitpid), and I can't see where this might happen. Just before
> end_wait4, it does do something potentially dangerous in that it
> leaves retval set to -ERESTARTSYS, but in all of the code paths I can
> see, retval gets reset before it exits. The only thing I can think of
> is a compiler bug; what version of gcc are you using?
>
> Puzzled
Ted,
it's caused by exec_usermodehelper(). From within unregister_netdevice()
we fork a kernel thread and try to exec /sbin/hotplug. Then
we call waitpid() which gets interrupted by the SIGCHLD. We need to
handle signals correctly around the exec. This and many other things
are fixed with this patch:
--- linux-2.4.0-test12-pre4/include/linux/sched.h Mon Dec 4 21:07:13 2000
+++ linux-akpm/include/linux/sched.hTue Dec 5 00:36:08 2000
@@ -150,6 +150,7 @@
asmlinkage void schedule(void);
extern void schedule_task(struct tq_struct *task);
+extern int start_context_thread(void);
/*
* The default fd array needs to be at least BITS_PER_LONG,
--- linux-2.4.0-test12-pre4/kernel/kmod.c Tue Nov 21 20:11:21 2000
+++ linux-akpm/kernel/kmod.cTue Dec 5 00:36:08 2000
@@ -165,7 +165,7 @@
int request_module(const char * module_name)
{
- int pid;
+ pid_t pid;
int waitpid_result;
sigset_t tmpsig;
int i;
@@ -259,40 +259,121 @@
static int exec_helper (void *arg)
{
+ long ret;
void **params = (void **) arg;
char *path = (char *) params [0];
char **argv = (char **) params [1];
char **envp = (char **) params [2];
- return exec_usermodehelper (path, argv, envp);
+
+ ret = exec_usermodehelper (path, argv, envp);
+ if (ret < 0)
+ ret = -ret;
+ do_exit(ret);
}
+struct subprocess_info {
+ struct semaphore *sem;
+ char *path;
+ char **argv;
+ char **envp;
+ int retval;
+};
-int call_usermodehelper (char *path, char **argv, char **envp)
+/*
+ * This is a standalone child of keventd. It forks off another thread which
+ * is the desired usermode helper and then waits for the child to exit.
+ * We return the usermode process's exit code, or some -ve error code.
+ */
+static int call_usermodehelper(void *data)
{
- void *params [3] = { path, argv, envp };
- int pid, pid2, retval;
+ struct subprocess_info *sub_info = data;
+ struct task_struct *curtask = current;
+ void *params [3] = { sub_info->path, sub_info->argv, sub_info->envp };
+ pid_t pid, pid2;
mm_segment_t fs;
+ int retval = 0;
- if ( ! current->fs->root ) {
- printk(KERN_ERR "call_usermodehelper[%s]: no root fs\n",
- path);
- return -EPERM;
- }
- if ((pid = kernel_thread (exec_helper, (void *) params, 0)) < 0) {
- printk(KERN_ERR "failed fork %s, errno = %d", argv [0], -pid);
- return -1;
- }
+ if (!curtask->fs->root) {
+ printk(KERN_ERR "call_usermodehelper[%s]: no root fs\n",
+sub_info->path);
+ retval = -EPERM;
+ goto up_and_out;
+ }
+ if ((pid = kernel_thread(exec_helper, (void *) params, 0)) < 0) {
+ printk(KERN_ERR "failed fork2 %s, errno = %d", sub_info->argv[0],
+-pid);
+ retval = pid;
+ goto up_and_out;
+ }
+
+ if (retval >= 0) {
+ /* Block everything but SIGKILL/SIGSTOP */
+ spin_lock_irq(>sigmask_lock);
+ siginitsetinv(>blocked, sigmask(SIGKILL) | sigmask(SIGSTOP));
+ recalc_sigpending(curtask);
+ spin_unlock_irq(>sigmask_lock);
+
+ /* Allow the system call to access kernel memory */
+ fs = get_fs();
+ set_fs(KERNEL_DS);
+ pid2 = waitpid(pid, , __WCLONE);
+ if (pid2 == -1 && errno < 0)
+ pid2 = errno;
+ set_fs(fs);
+
+ if (pid2 != pid) {
+ printk(KERN_ERR "waitpid(%d) failed, %d\n", pid, pid2);
+ retval = (pid2 < 0) ? pid2 : -1;
+ }
+ }
+
+up_and_out:
+ sub_info->retval = retval;
+ curtask->exit_signal = SIGCHLD; /* Wake up parent */
+ up_and_exit(sub_info->sem, retval);
+}
- fs = get_fs ();
- set_fs (KERNEL_DS);
- pid2 = waitpid (pid, , __WCLONE);
- set_fs (fs);
+/*
+
Re: 2.4.0-test12-pre4 + cs46xx + KDE 2.0 = frozen system
Alan Cox wrote:
>> > Crystal 4280/461x + AC97 Audio, version 0.14, 13:39:25 Dec 4 2000
>> > cs461x: Card found at 0xf8ffe000 and 0xf8e0, IRQ 18
>> > cs461x: Unknown card (:) at 0xf8ffe000/0xf8e0, IRQ 18
>> > ac97_codec: AC97 Audio codec, id: 0x4352:0x5914 (Unknown)
>>
>> This is failing to detect the CS46xx. I assume someone has fiddled with the
>> driver. Does it work correctly on your machine in 2.2.18pre24 ?
I believe it did for 2.2.18pre23. I'll try out 2.2.18pre24 and your
following patch when I'm back at work about 12 hours from now.
Thanks!
Steven Cole
Alan Cox wrote:
>
>A follow on question. This may be 2.4 PCI changes. That would mean you might
>want..
>
>--- drivers/sound/cs46xx.c~Sat Dec 2 01:44:21 2000
>+++ drivers/sound/cs46xx.c Mon Dec 4 22:58:58 2000
>@@ -2534,6 +2534,11 @@
> struct cs_card *card;
> struct cs_card_type *cp = [0];
>
>+ if (pci_enable_device(pci_dev)<0)
>+ {
>+ printk(KERN_ERR "cs461x: unable to enable\n");
>+ return -EIO;
>+ }
> if ((card = kmalloc(sizeof(struct cs_card), GFP_KERNEL)) == NULL) {
> printk(KERN_ERR "cs461x: out of memory\n");
> return -ENOMEM;
I'll apply that patch tomorrow.
Steven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] livelock in elevator scheduling
Jens Axboe wrote:
> On Fri, Dec 01 2000, Russell Cattelan wrote:
> > > If performance is down, then that problem is most likely elsewhere.
> > > I/O limited benchmarking typically thrives on lots of request
> > > latency -- with that comes better throughput for individual threads.
> > >
> > > > Anyway, I'll try your patch.
> >
> > Well this patch does help with the request starvation problem.
> > Unfortunately it has introduced another problem.
> > Running 4 doio programs, on and XFS partion with KIO buf IO turned on.
>
> This looks like a generic aic7xxx problem, and not block related. Since
> you are doing such nice traces, what is the other CPU doing? CPU1
> seems to be stuck grabbing the io_request_lock (for reasons not entirely
> clear from reading the aic7xxx source...)
>
Ok Keith gave me a quick hack to help with the race condition.
Here is the latest set up back traces...
The actually accuracy of these back traces... well? who knows, but it does
give us something to go on.
It doesn't make much sense to me right now, but I'm guessing the problem is
starting with that do_div error.
I'm going to take a closer look at the scsi_back_merge_fn.
This may have more to due with our/Chait's kiobuf modifications than
anything else.
XFS (dev: 8/20) mounting with KIOBUFIO
Start mounting filesystem: sd(8,20)
Ending clean XFS mount for filesystem: sd(8,20)
kmem_alloc doing a vmalloc 262144 size & PAGE_SIZE 0 rval=0xe0a1
Unable to handle kernel NULL pointer dereference at virtual address
0008
printing eip:
c019f8b5
*pde =
Entering kdb (current=0xc191, pid 5) on processor 1 Panic: Oops
due to panic @ 0xc019f8b5
eax = 0x0002 ebx = 0x0001 ecx = 0x00081478 edx = 0x
esi = 0xc1957da0 edi = 0xc1923ac8 esp = 0xc1911e94 eip = 0xc019f8b5
ebp = 0xc1911e9c xss = 0x0018 xcs = 0x0010 eflags = 0x00010046
xds = 0x0018 xes = 0x0018 origeax = 0x = 0xc1911e60
[1]kdb> bt
EBP EIP Function(args)
0xc1911e9c 0xc019f8b5 scsi_back_merge_fn_c+0x15 (0xc1923a98,
0xc1957da0, 0xcfb05780, 0x80)
kernel .text 0xc010 0xc019f8a0
0xc019f98c
0xc1911f2c 0xc016a0df __make_request+0x1af (0xc1923a98, 0x1,
0xcfb05780, 0x0, 0x814)
kernel .text 0xc010 0xc0169f30
0xc016a8a4
0xc1911f70 0xc016a9c8 generic_make_request+0x124 (0x1, 0xcfb05780,
0x0, 0x0, 0x0)
kernel .text 0xc010 0xc016a8a4
0xc016aa50
0xc1911fac 0xc016abde ll_rw_block+0x18e (0x1, 0x1, 0xc1911fd0, 0x0)
kernel .text 0xc010 0xc016aa50
0xc016ac58
0xc1911fd4 0xc0138ed7 flush_dirty_buffers+0x97 (0x0, 0x10f00)
kernel .text 0xc010 0xc0138e40
0xc0138f24
0xc1911fec 0xc01391ab bdflush+0x8f
kernel .text 0xc010 0xc013911c
0xc0139260
0xc0108c9b kernel_thread+0x23
kernel .text 0xc010 0xc0108c78
0xc0108cb0
[1]kdb> go
Oops:
CPU:1
EIP:0010:[]
EFLAGS: 00010046
eax: 0002 ebx: 0001 ecx: 00081478 edx:
esi: c1957da0 edi: c1923ac8 ebp: c1911e9c esp: c1911e94
ds: 0018 es: 0018 ss: 0018
Process kflushd (pid: 5, stackpage=c1911000)
Stack: cfb05780 c1923a98 c1911f2c c016a0df c1923a98 c1957da0 cfb05780
0080
0814 00081478 cfb05780 0008 0001 0200
c1923ac0
000e c191 c1911efc c010c77e 0246 0814
def0e800
Call Trace: [] [] [] []
[] [] []
[]
Code: 66 81 7a 08 00 10 0f 47 d8 8b 4a 2c 85 c9 74 19 0f b7 42 08
NMI Watchdog detected LOCKUP on CPU0, registers:
CPU:0
EIP:0010:[]
EFLAGS: 0086
eax: c01b21ac ebx: c197b078 ecx: edx: 0012
esi: 0286 edi: c02f5f94 ebp: c02f5f44 esp: c02f5f38
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, stackpage=c02f5000)
Stack: c190fb20 0401 c02f5f64 c010c539 0012 c197b078
c02f5f94
0240 c0331a40 0012 c02f5f8c c010c73d 0012 c02f5f94
c190fb20
c0108960 c02f4000 c0108960 c190fb20 c02f5fc8 c010a8c8
c0108960
Call Trace: [] [] [] []
[] [] []
[] [] [] [] []
Code: 80 3d 64 47 2e c0 00 f3 90 7e f5 e9 1b a7 f9 ff 80 3d 64 e3
Entering kdb (current=0xc02f4000, pid 0) on processor 0 due to WatchDog
Interrupt @ 0xc0217a98
eax = 0xc01b21ac ebx = 0xc197b078 ecx = 0x edx = 0x0012
esi = 0x0286 edi = 0xc02f5f94 esp = 0xc02f5f38 eip = 0xc0217a98
ebp = 0xc02f5f44 xss = 0x0018 xcs = 0x0010 eflags = 0x0086
xds = 0x0018 xes = 0xc02f0018 origeax = 0xc01b21ac = 0xc02f5f04
[0]kdb> bt
EBP EIP Function(args)
0xc0217a98 stext_lock+0x43a8
kernel .text.lock 0xc02136f0 0xc02136f0
0xc02197c0
0xc02f5f44 0xc01b21c3 do_aic7xxx_isr+0x17 (0x12, 0xc197b078,
0xc02f5f94, 0x240, 0xc0331a40)
Re: 2.4.0-test11: kernel: waitpid(823) failed, -512
On Sun, Dec 03, 2000 at 11:36:11PM +0100, Frank van Maarseveen wrote: > While playing with routing (zebra) and PPP I regularly see this > message appearing. It always happens when pppd terminates a connection, > e.g: > Dec 3 23:09:08 mimas kernel: waitpid(823) failed, -512 This means a system call returned with an error code of -ERESTARTSYS when a signal wasn't pending; this is a kernel bug. However, I've looked at the code to sys_wait4 (which implements waitpid), and I can't see where this might happen. Just before end_wait4, it does do something potentially dangerous in that it leaves retval set to -ERESTARTSYS, but in all of the code paths I can see, retval gets reset before it exits. The only thing I can think of is a compiler bug; what version of gcc are you using? Puzzled, - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test12-pre4 boot failure (better than pre3 and lower)
> Most architectures dump their code as a string of bytes and print the > code after the registers and trace back. Alpha dumps the code before > the trace and also decodes the instructions which really confuses > ksymoops. Somebody changed 'Trace: ' to 'Trace:' between 2.2 and 2.4 > kernels so ksymoops no longer picks the trace data. > > Is there any chance of changing arch/alpha/kernel/traps.c to print > registers, trace and _raw_ code, in that order so it is more like other > architectures? You can print the decoded instructions as well (prefix > Decode:, not Code:) as long as the raw code bytes are also available. > > In the meantime, this patch to ksymoops 2.3.5 will pick up the change > to the trace lines. It will still complain about a bad code line, > ksymoops is built for raw data. Didn't help much: [wakko@kakarot:/home/wakko/ksymoops-2.3.4] ./ksymoops -v /usr/src/2.4.0-test12-pre4/vmlinux -K -L -O -m /usr/src/2.4.0-test12-pre4/System.map < /rod/home/wakko/240t12p4-boot ksymoops 2.3.4 on alpha 2.2.17-LVM-RAID. Options used -v /usr/src/2.4.0-test12-pre4/vmlinux (specified) -K (specified) -L (specified) -O (specified) -m /usr/src/2.4.0-test12-pre4/System.map (specified) Unable to handle kernel paging request at virtual address 0010 swapper(53): Oops 0 pc = [] ra = [] ps = Using defaults from ksymoops -t elf64-alpha -a alpha v0 = t0 = 0012 t1 = fc485748 t2 = fc0009f5c560 t3 = fc46cfb0 t4 = t5 = fffe t6 = t7 = fc0009e0 s0 = fc323600 s1 = s2 = fc0009f5c560 s3 = fc0009f5c560 s4 = fc0009eb0ac0 s5 = fc0009eb0ac0 s6 = fc0009eb0ac0 a0 = fc4870c8 a1 = fc0009e00050 a2 = fc4871c8 a3 = a4 = 0001 a5 = t8 = 0001 t9 = 0003 t10= 0004 t11= 0010 pv = fc323600 at = gp = fc4a3f58 sp = fc0009dffee0 Code: 40203001 addl t0,1,t0 Warning (Oops_code): trailing garbage ignored on Code: line Text: 'Code: 40203001 addl t0,1,t0' Garbage: 'l t0,1,t0' Error (Oops_code_values): invalid value 0xadd in Code line, must be 2, 4, 8 or 16 digits, value ignored >>PC; fc323270<= Code; fc323270 <_PC>: Code; fc323270 0: 01 30 20 40 addl t0,0x1,t0 b82b stl_c t0,0(s2) e42001fe blt t0,.+2044 b57e0148 stq s2,328(sp) a5480428 ldq s1,1064(t7) a0220008 ldl t0,8(t1) a52a0028 ldq s0,40(s1) Trace:323658 323600 Unable to handle kernel paging request at virtual address 0010 swapper(54): Oops 0 pc = [] ra = [] ps = v0 = t0 = 0012 t1 = fc485748 t2 = fc0009f5c560 t3 = fc46cfb0 t4 = t5 = fffe t6 = t7 = fc0009e0 s0 = fc323600 s1 = s2 = fc0009f5c560 s3 = fc0009f5c560 s4 = fc0009eb0ac0 s5 = fc0009eb0ac0 s6 = fc0009eb0ac0 a0 = fc4870c8 a1 = fc0009e00050 a2 = fc4871c8 a3 = a4 = 0001 a5 = t8 = 0001 t9 = 0003 t10= 0004 t11= 0010 pv = fc323600 at = gp = fc4a3f58 sp = fc0009dffee0 Code: 40203001 addl t0,1,t0 Warning (Oops_code): trailing garbage ignored on Code: line Text: 'Code: 40203001 addl t0,1,t0' Garbage: 'l t0,1,t0' Error (Oops_code_values): invalid value 0xadd in Code line, must be 2, 4, 8 or 16 digits, value ignored Trace; 00323658 Before first symbol Trace; 00323600 Before first symbol >>PC; fc323270<= Code; fc323270 <_PC>: Code; fc323270 0: 01 30 20 40 addl t0,0x1,t0 b82b stl_c t0,0(s2) e42001fe blt t0,.+2044 b57e0148 stq s2,328(sp) a5480428 ldq s1,1064(t7) a0220008 ldl t0,8(t1) a52a0028 ldq s0,40(s1) Trace:323658 323600 Unable to handle kernel paging request at virtual address 0010 swapper(56): Oops 0 pc = [] ra = [] ps = v0 = t0 = 0012 t1 = fc485748 t2 = fc0009f5c560 t3 = fc46cfb0 t4 = t5 = fffe t6 = t7 = fc0009e0 s0 = fc323600 s1 = s2 = fc0009f5c560 s3 = fc0009f5c560 s4 = fc0009eb0ac0 s5 = fc0009eb0ac0 s6 = fc0009eb0ac0 a0 = fc4870c8 a1 = fc0009e00050 a2 = fc4871c8 a3 = a4 = 0001 a5 = t8 = 0001 t9 = 0003 t10= 0004 t11= 0010 pv = fc323600 at = gp = fc4a3f58 sp = fc0009dffee0 Code: 40203001 addl t0,1,t0 Warning (Oops_code):
Problems with Athlon CPU
Hello There is probably not a kernel bug, but bug in gcc, but... :) [root@beer linux]# make bzImage [snip] gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686-DEXPORT_SYMTAB -c selection.c In file included from /usr/src/linux/include/asm/smp.h:21, from /usr/src/linux/include/linux/smp.h:14, from /usr/src/linux/include/linux/sched.h:22, from selection.c:16: /usr/src/linux/include/asm/apic.h:13:29: warning: nothing can be pasted after this token gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686-DEXPORT_SYMTAB -c serial.c In file included from /usr/src/linux/include/asm/smp.h:21, from /usr/src/linux/include/linux/smp.h:14, from /usr/src/linux/include/linux/sched.h:22, from serial.c:183: /usr/src/linux/include/asm/apic.h:13:29: warning: nothing can be pasted after this token serial.c: In function `line_info': serial.c:3241: Internal error: Segmentation fault. Please submit a full bug report. See http://www.gnu.org/software/gcc/bugs.html> for instructions. make[3]: *** [serial.o] Error 2 make[3]: Leaving directory `/usr/src/linux/drivers/char' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/src/linux/drivers/char' make[1]: *** [_subdir_char] Error 2 make[1]: Leaving directory `/usr/src/linux/drivers' make: *** [_dir_drivers] Error 2 I have tried compiled it on AMD Athlon Processor with glibc 2.2. I have tried to compile kernels: 2.2.17, 2.2.18pre-24, 2.4.0-test11 and always I have got this message. With glibc 2.1.94 I had not any problems with compilation! [lukasz@beer lukasz]$ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 3 model name : AMD Athlon(tm) Processor stepping: 0 cpu MHz : 600.043 cache size : 1 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 6 mce cx8 sep mtrr pge 14 cmov fcmov 17 psn 22 mmx 24 30 3dnow bogomips: 1196.03 [lukasz@beer lukasz]$ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 2731 (Red Hat Linux 7.0) [lukasz@beer lukasz]$ rpm -q glibc glibc-2.2-5 Any sugestions? On others machines with AMD-K6 or Petnium-III/II and with the same version of glibc and gcc that problems does not exists! ps sorry for my broken english. :( -- *[ ukasz Trbiski ]* SysAdmin @wsisiz.edu.pl - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PROBLEM: Kernel Oops 10% of diskless boots
Following the form:
[1.] PROBLEM: Kernel Oops 10% of diskless boots
[2.] When booting a diskless workstation (etherboot) the boot will fail
with an Oops, roughly 10% of the time. This has remained the failure
rate for quite some time. The included Oops if from 2.4.0-test12-pre4.
Similar crashing is seen with Intel, as well as AMD (below). Maybe
something is uninitialized in the case of root on NFS???
[3.] diskless boot oops nfsroot
[4.] 2.4.0-test12 (pre4)
[5.]
Kernel command line: auto rw root=/dev/nfs nfsroot=/diskless/%s
console=ttyS0,9600 ramdisk
_size=6144 ip=192.168.15.82:192.168.15.55:192.168.15.1:255.255.255.0:
Initializing CPU#0
Detected 901.614 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1795.69 BogoMIPS
Memory: 123820k/131008k available (1872k kernel code, 6800k reserved,
136k data, 220k init
, 0k highmem)
Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
CPU: Before vendor init, caps: 0183f9ff c1c7f9ff , vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0183f9ff c1c7f9ff
CPU: After generic, caps: 0183f9ff c1c7f9ff
CPU: Common caps: 0183f9ff c1c7f9ff
CPU: AMD Athlon(tm) Processor stepping 02
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
PCI: PCI BIOS revision 2.10 entry at 0xfb260, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unable to handle kernel NULL pointer dereference at virtual address
printing eip:
c1236000
*pde =
Oops: 0002
CPU:0
EIP:0010:[]
EFLAGS: 00010246
eax: ebx: c1236000 ecx: 00236000 edx: 003c
esi: c1236264 edi: c1236284 ebp: esp: c123dcb8
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 1, stackpage=c123d000)
Stack: c1236000 c123dfa4 0600 c030f819 c1236000
c123dd20
03051106 c030f884 c123dd20 c123dd20
c12374c0 c030f900 c123dd20 c12374c0 c02d5fc4
c0105000
Call Trace: [] [] [] []
Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0 74 23 c1
Kernel panic: Attempted to kill init!
>>EIP; c1236000 <_end+ed6f6c/84a2f6c> <=
Trace; c0105000
Trace; c02649a8
Trace; c01070df
Trace; c0107517
Code; c1236000 <_end+ed6f6c/84a2f6c> <=
<_EIP>: <=
Code; c1236010 <_end+ed6f7c/84a2f6c>
10: c0(bad)
Code; c1236011 <_end+ed6f7d/84a2f6c>
11: 74 23 je 36 <_EIP+0x36> c1236036
<_end+ed6fa2/84a2f6c>
Code; c1236013 <_end+ed6f7f/84a2f6c>
13: c1 00 00 roll $0x0,(%eax)
[7.1]
Linux linux82.integrity.com 2.4.0-test12-diskless #2 Mon Dec 4 12:03:22
MST 2000 i686 unknown
Kernel modules found
Gnu C 2.96
Binutils 2.10.0.18
Linux C Library..
ldd: missing file arguments
Try `ldd --help' for more information.
ls: /usr/lib/libg++.so: No such file or directory
Procps 2.0.7
Mount 2.10m
Net-tools (2000-05-21)
Kbd[option...]
Sh-utils 2.0
Sh-utils Parker.
Sh-utils
Sh-utils Inc.
Sh-utils NO
Sh-utils PURPOSE.
[7.2]
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 4
model name : AMD Athlon(tm) Processor
stepping: 2
cpu MHz : 901.000607
cache size : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
features: fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips: 1795.69
[7.3]
via82cxxx_audio15864 0 (unused)
soundcore 4004 2 [via82cxxx_audio]
ac97_codec 7972 0
[via82cxxx_audio]
[7.4]
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
01f0-01f7 : ide0
02f8-02ff : serial(auto)
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(auto)
0cf8-0cff : PCI conf1
4000-40ff : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
5000-500f : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
d000-d00f : VIA Technologies, Inc. Bus Master IDE
d000-d007 : ide0
d008-d00f : ide1
d400-d41f : VIA Technologies, Inc. UHCI USB
d400-d41f : usb-uhci
d800-d81f : VIA Technologies, Inc. UHCI USB (#2)
d800-d81f : usb-uhci
dc00-dcff : VIA Technologies, Inc. AC97 Audio Controller
dc00-dcff : via82cxxx
e000-e003
Re: Posible Bug at page_alloc.c in the [2.4.0-test11] kernel
Am Tue, 5 Dec 2000 schrieb [EMAIL PROTECTED] : > On Tue, Dec 05, 2000 at 01:04:05AM +0100, Stefan Pfetzing wrote: > > Hello, > > > > I think i possibly foun a Bug in the Linux Kernel 2.4.0-test11. > > I patched the kernel with the bttv driver 7.49 but nothing else. > > My system was up for 5 1/2 days and than it crashed. > > [ page_alloc: BUG at line 84 ] > > That's interesting. Could you double check that you run 2.4.0-test11 > and not 2.4.0-test12preX? There has been at least one reports of this > very bug and two others that look related. However, it looked like a > test12-pre[34] problem - until now. > no please believe me it IS 2.4.0-test11 uname -a: Linux server 2.4.0-test11 #3 Tue Nov 28 21:15:01 CET 2000 i586 unknow > > [ ... ] > > If i forgot anything (kernel config or anything else please mail me. > > The compiler version you are using is always an interesting data point. > But I doubt that this is the problem here. the gcc is version 2.95.2 > > Gruesse Christian > cu dreamind p.s.:please reply ALSO to my private address because I am NOT on the mailing-list. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Posible Bug at page_alloc.c in the [2.4.0-test11] kernel
On Tue, Dec 05, 2000 at 01:04:05AM +0100, Stefan Pfetzing wrote: > Hello, > > I think i possibly foun a Bug in the Linux Kernel 2.4.0-test11. > I patched the kernel with the bttv driver 7.49 but nothing else. > My system was up for 5 1/2 days and than it crashed. > [ page_alloc: BUG at line 84 ] That's interesting. Could you double check that you run 2.4.0-test11 and not 2.4.0-test12preX? There has been at least one reports of this very bug and two others that look related. However, it looked like a test12-pre[34] problem - until now. > [ ... ] > If i forgot anything (kernel config or anything else please mail me. The compiler version you are using is always an interesting data point. But I doubt that this is the problem here. Gruesse Christian -- THAT'S ALL FOLKS! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Posible Bug at page_alloc.c in the [2.4.0-test11] kernel
Hello, I think i possibly foun a Bug in the Linux Kernel 2.4.0-test11. I patched the kernel with the bttv driver 7.49 but nothing else. My system was up for 5 1/2 days and than it crashed. I have a Pentium 200MMX (overclocked to 225 but I REALLY don't think that's the problem, because it worked fine with other Kernels.), a Asus TX97 Board, 64MB Ram, an Nvidia Riva 128 graphics card, a Hauppauge TV Card, a AVM Isdn Card, a Symbios Logic SCSI Card and of course a D-Link network card (tulip based). I also have several Usb devices attached (Monitor, Keyboard and Mouse) At the moment when the kernel crashed, I was online (via ISDN) and I just closed xawv (tv viewing program) and started playing a mp3 via mp3blaster. (hope this information isn't too accurate) /var/log/messages: ---snipp--- Dec 4 23:50:57 server kernel: kernel BUG at page_alloc.c:84! Dec 4 23:50:57 server kernel: invalid operand: Dec 4 23:50:57 server kernel: CPU:0 Dec 4 23:50:57 server kernel: EIP:0010:[__free_pages_ok+73/892] Dec 4 23:50:57 server kernel: EFLAGS: 00010286 Dec 4 23:50:57 server kernel: eax: 001f ebx: c1013210 ecx: edx: Dec 4 23:50:57 server kernel: esi: c1013238 edi: ebp: 001e esp: c1165f64 Dec 4 23:50:57 server kernel: ds: 0018 es: 0018 ss: 0018 Dec 4 23:50:57 server kernel: Process kswapd (pid: 3, stackpage=c1165000) Dec 4 23:50:57 server kernel: Stack: c01df9a5 c01dfb73 0054 c1013210 c1013238 0091 001e 0091 Dec 4 23:50:57 server kernel:001d 0003 c0128882 c012a127 c0128a69 0004 Dec 4 23:50:57 server kernel: 0004 c01290d0 0004 Dec 4 23:50:57 server kernel: Call Trace: [tvecs+7389/60504] [tvecs+7851/60504] [page_launder+670/1900] [__free_pa Dec 4 23:50:57 server kernel:[kswapd+115/316] [kernel_thread+40/56] Dec 4 23:50:57 server kernel: Code: 0f 0b 83 c4 0c 89 f6 89 da 2b 15 b8 fd 26 c0 89 d0 c1 e0 04 Dec 4 23:51:23 server kernel: kernel BUG at vmscan.c:533! Dec 4 23:51:23 server kernel: invalid operand: Dec 4 23:51:23 server kernel: CPU:0 Dec 4 23:51:23 server kernel: EIP:0010:[reclaim_page+901/988] Dec 4 23:51:23 server kernel: EFLAGS: 00010286 Dec 4 23:51:23 server kernel: eax: 001c ebx: c101322c ecx: edx: 0010 Dec 4 23:51:23 server kernel: esi: c1013210 edi: c06ab5bc ebp: esp: c3491e10 Dec 4 23:51:23 server kernel: esi: c1013210 edi: c06ab5bc ebp: esp: c3491e10 Dec 4 23:51:23 server kernel: ds: 0018 es: 0018 ss: 0018 Dec 4 23:51:23 server kernel: Process xglobe (pid: 14216, stackpage=c3491000) Dec 4 23:51:23 server kernel: Stack: c01df405 c01df5c4 0215 c020e6e0 c020e974 c0129dc8 Dec 4 23:51:23 server kernel:c020e6e0 c020e978 0001 c0129f83 c020e96c Dec 4 23:51:23 server kernel: 0001 c1024188 00a3 c1a79bbc 0005 0001 Dec 4 23:51:23 server kernel: Call Trace: [tvecs+5949/60504] [tvecs+6396/60504] [__alloc_pages_limit+124/172] [__a Dec 4 23:51:23 server kernel:[handle_mm_fault+232/340] [do_page_fault+311/1004] [do_page_fault+0/1004] [do Dec 4 23:51:23 server kernel: Code: 0f 0b 83 c4 0c 31 c0 0f b3 46 18 8d 5e 28 8d 46 2c 39 46 2c Dec 4 23:55:00 server /USR/SBIN/CRON[14222]: (root) CMD ( ping www.heise.de -c1 >/dev/null ) Dec 4 23:55:43 server kernel: usb-uhci.c: interrupt, status 3, frame# 100 ---snipp--- If i forgot anything (kernel config or anything else please mail me. And please also mail to my address in replys because I am NOT suscribed to the mailing list. thanx dreamind - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: multiprocessor kernel problem
Rusty Russell <[EMAIL PROTECTED]> writes: > In message <[EMAIL PROTECTED]> you write: > > yes, but is it a dual machine or is it an N-way SMP with N > 2? the > > other guy with iptables/SMP problems also has a quad box. could this > > perhaps be a problem only when you have more than two processors? > > Yes, hacked my machine to think it had 4 cpus, and boom. > > There are two problems: > (1) initialization of multiple tables was wrong, and > (2) iterating through tables should not use cpu_number_map (doesn't > matter on X86 though). > > Please try attached patch. ok i'll give this a whirl success! netfilter/iptables seems to be up and working on my quad ppro box now. i am running your "quick guide to firewalling" from the howto until i get my rules straightened out. thank you very much. johan -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PM in 2.2
On Tue, Dec 05, 2000 at 12:19:17AM +0100, J . A . Magallon wrote: > Hi everyone. > > I would like to know if there is any back-port of ACPI to 2.2. > Problem: 2-way machine, so APM does not work. > I would love my box powers down when I shutdown...just like macs. Make sure APM is compiled in and put append="apm=power-off" into your lilo.conf -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
SCSI Oops (was test12-pre4)
(cross-posted to linux-kernel and linux-scsi) Hi, The SCSI oops I reported last week is still present in test12-pre4. This is on a Dell PowerEdge 6300. It has two Adaptec AIC-7890, one Adaptec AIC-7860, and an AMI MegaRAID controller. There's nothing on the 7890s, a CDROM and a tape drive on the 7890. With all of the above enabled the kernel boots with no problems. However, if I disable the two 7890s from the BIOS (to save 30 seconds of boot time), I get an oops. The decoded oops is below. Please email me directly for further information. Thanks, Borislav ksymoops 2.3.5 on i686 2.4.0-test12. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test12/ (default) -m linux-2.4.0-test12-pre4/System.map (specified) activating NMI Watchdog ... done. cpu: 0, clocks: 37, slice: 199987 cpu: 1, clocks: 37, slice: 199987 cpu: 2, clocks: 37, slice: 199987 cpu: 3, clocks: 37, slice: 199987 Unable to handle kernel NULL pointer dereference at virtual address 0001 c019698f *pde = Oops: CPU:1 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010046 eax: f7dd ebx: 00ff ecx: edx: 00ff esi: edi: ebp: esp: c2139b80 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 1, stackpage=c2139000) Stack: f7dd f7dd2878 f7dd2a34 0028 ff00 c01980c2 f7dd2878 f7dd 00ff f7dd2878 f7de3200 f7de3200 00ff 001135d0 ff1aa8c3 c01aaec8 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8a 57 01 88 d0 c0 e8 04 0f b6 d8 89 5c 24 10 88 d0 c0 e8 03 >>EIP; c019698f<= Trace; ff00 Trace; c01980c2 Trace; ff1aa8c3 Trace; c01aaec8 Trace; c01ab143 Trace; c01ab3d8 Trace; c018b613 Trace; c018b6a2 Trace; c019025c Trace; c0191adc Trace; c0190f9b Trace; c018b872 Trace; c018b772 Trace; c018b1d8 Trace; c01946a1 Trace; c012f494 <__get_free_pages+14/24> Trace; c01200ff Trace; c016ea3d Trace; c021f3f4 Trace; c016eaca Trace; c018b1cc Trace; c01944c6 Trace; c0105000 Trace; c017512b Trace; c01218a4 Trace; c0112156 Trace; c011a9f1 Trace; c0105000 Trace; c018c647 Trace; c0105000 Trace; c014f1e4 Trace; c0105000 Trace; c0105000 Trace; c018cd1d Trace; c0107031 Trace; c0105000 Trace; c0109153 Code; c019698f <_EIP>: Code; c019698f<= 0: 8a 57 01 mov0x1(%edi),%dl <= Code; c0196992 3: 88 d0 mov%dl,%al Code; c0196994 5: c0 e8 04 shr$0x4,%al Code; c0196997 8: 0f b6 d8 movzbl %al,%ebx Code; c019699a b: 89 5c 24 10 mov%ebx,0x10(%esp,1) Code; c019699e f: 88 d0 mov%dl,%al Code; c01969a0 11: c0 e8 03 shr$0x3,%al Kernel panic: Attempted to kill init! activating NMI Watchdog ... done. cpu: 0, clocks: 48, slice: 199989 cpu: 1, clocks: 48, slice: 199989 cpu: 2, clocks: 48, slice: 199989 cpu: 3, clocks: 48, slice: 199989 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: aacraid for 2.4.0
Keith Owens wrote: > > On Mon, 4 Dec 2000 17:31:04 -0500 , > "Boerner, Brian" <[EMAIL PROTECTED]> wrote: > >The driver > >is generating a segmentation fault and produces and oops. I have included > >Code: 00 00 00 00 00 00 00 00 b8 00 00 00 83 ec 34 68 00 2c 82 c8 > > That code looks bad. I suspect you are using an old modutils on > current kernels. modutils < 2.3.15 incorrectly load modules on recent > kernels, you should be running modutils 2.3.21 for 2.4 kernels. This can happen if you get your __devinit and __devinitdata declarations tangled up. If you have a table which is declared __devinit instead of __devinitdata then subsequently declared functions end up with their text being placed in the rodata section. You only find out about this because the assembler pads .align statements with nulls. Hard to find. So if the modutils upgrade doesn't help, remove all `init' thingies and see if the problem goes away. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test12-pre4 + cs46xx + KDE 2.0 = frozen system
> > Crystal 4280/461x + AC97 Audio, version 0.14, 13:39:25 Dec 4 2000
> > cs461x: Card found at 0xf8ffe000 and 0xf8e0, IRQ 18
> > cs461x: Unknown card (:) at 0xf8ffe000/0xf8e0, IRQ 18
> > ac97_codec: AC97 Audio codec, id: 0x4352:0x5914 (Unknown)
>
> This is failing to detect the CS46xx. I assume someone has fiddled with the
> driver. Does it work correctly on your machine in 2.2.18pre24 ?
A follow on question. This may be 2.4 PCI changes. That would mean you might
want..
--- drivers/sound/cs46xx.c~ Sat Dec 2 01:44:21 2000
+++ drivers/sound/cs46xx.c Mon Dec 4 22:58:58 2000
@@ -2534,6 +2534,11 @@
struct cs_card *card;
struct cs_card_type *cp = [0];
+ if (pci_enable_device(pci_dev)<0)
+ {
+ printk(KERN_ERR "cs461x: unable to enable\n");
+ return -EIO;
+ }
if ((card = kmalloc(sizeof(struct cs_card), GFP_KERNEL)) == NULL) {
printk(KERN_ERR "cs461x: out of memory\n");
return -ENOMEM;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] livelock in elevator scheduling
Jens Axboe wrote: > On Fri, Dec 01 2000, Russell Cattelan wrote: > > > If performance is down, then that problem is most likely elsewhere. > > > I/O limited benchmarking typically thrives on lots of request > > > latency -- with that comes better throughput for individual threads. > > > > > > > Anyway, I'll try your patch. > > > > Well this patch does help with the request starvation problem. > > Unfortunately it has introduced another problem. > > Running 4 doio programs, on and XFS partion with KIO buf IO turned on. > > This looks like a generic aic7xxx problem, and not block related. Since > you are doing such nice traces, what is the other CPU doing? CPU1 > seems to be stuck grabbing the io_request_lock (for reasons not entirely > clear from reading the aic7xxx source...) > Sorry I haven't been able to get a decent backtrace of the other processor. According to Keith Owens the maintainer of kdb there is a race condition in kbd and the NMI loop detection stuff that resulting in not being able to switch cpus. I'll keep try to dig up some more info. I'm also seeing various other panics in XFS (well pagebuf to be specific) with this patch. Nothing seems to be very consistent and this point. Ok I did manage to switch processors. Entering kdb (current=0xd7c0a000, pid 645) on processor 1 due to cpu switch [1]kdb> bt EBP EIP Function(args) 0xc0216594 stext_lock+0x2ea4 kernel .text.lock 0xc02136f0 0xc02136f0 0xc02197c0 0xd7c0bf98 0xc0155964 ext2_sync_file+0x2c (0xd8257560, 0xd7348220, 0x0, 0xd7c0a000) kernel .text 0xc010 0xc0155938 0xc0155a40 0xd7c0bfbc 0xc0136064 sys_fsync+0x54 (0x1, 0xb020, 0x0, 0xb048, 0x8051738) kernel .text 0xc010 0xc0136010 0xc0136088 0xc010a807 system_call+0x33 kernel .text 0xc010 0xc010a7d4 0xc010a80c [1]kdb> > > -- > * Jens Axboe <[EMAIL PROTECTED]> > * SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test12-pre4 + cs46xx + KDE 2.0 = frozen system
> Crystal 4280/461x + AC97 Audio, version 0.14, 13:39:25 Dec 4 2000 > cs461x: Card found at 0xf8ffe000 and 0xf8e0, IRQ 18 > cs461x: Unknown card (:) at 0xf8ffe000/0xf8e0, IRQ 18 > ac97_codec: AC97 Audio codec, id: 0x4352:0x5914 (Unknown) This is failing to detect the CS46xx. I assume someone has fiddled with the driver. Does it work correctly on your machine in 2.2.18pre24 ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PM in 2.2
Hi everyone. I would like to know if there is any back-port of ACPI to 2.2. Problem: 2-way machine, so APM does not work. I would love my box powers down when I shutdown...just like macs. -- Juan Antonio Magallon Lacarta #> cd /pub mailto:[EMAIL PROTECTED] #> more beer Linux 2.2.18-pre24-vm #2 SMP Wed Nov 29 02:56:21 CET 2000 i686 unknown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: aacraid for 2.4.0
Andi Kleen writes: > On Mon, Dec 04, 2000 at 05:31:04PM -0500, Boerner, Brian wrote: > > EIP:0010:[] Note the value of EIP, and compare it with the structure size of "struct module". > > Code: 00 00 00 00 00 00 00 00 b8 00 00 00 83 ec 34 68 00 2c 82 c8 > ^^^ >... > Now you just have to find out why you're jumping to the bogus pointer. > It could e.g. be caused by a stack overwrite. Naaa, its old modutils. Upgrade to 2.3.21 and this problem will disappear. (explaination: with old modutils, the kernel "forgets" to copy some bytes into module space, which causes these zero'd bytes. modutils 2.3.21 fixes this. In addition, the kernel bug has also been fixed in the current pre patches, but this is not a recommendation to try the pre kernels out). _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: aacraid for 2.4.0
On Mon, 4 Dec 2000 17:31:04 -0500 , "Boerner, Brian" <[EMAIL PROTECTED]> wrote: >The driver >is generating a segmentation fault and produces and oops. I have included >Code: 00 00 00 00 00 00 00 00 b8 00 00 00 83 ec 34 68 00 2c 82 c8 That code looks bad. I suspect you are using an old modutils on current kernels. modutils < 2.3.15 incorrectly load modules on recent kernels, you should be running modutils 2.3.21 for 2.4 kernels. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test12-pre4 + cs46xx + KDE 2.0 = frozen system
Hi,
I am seeing something strange too, trying to reliably reproduce it
for a while - it is rare but irritating.
Most likely to happen on cold power on (first@evening)
--- X ---
XFree86 Version 3.3.6 / X Window System
(protocol Version 11, revision 0, vendor release 6300)
Release Date: January 8 1999
If the server is older than 6-12 months, or if your card is newer
than the above date, look for a newer version before reporting
problems. (see http://www.XFree86.Org/FAQ)
Operating System: Linux 2.2.14 i686 [ELF] SuSE
Voodo 3 2000 (PCI)
now running unaccelerated
--- KDE 2 ---
--- Audio, with or without audio ---
--- Kernel ---
2.2.16 or 2.4.0-testXX
I have more or less come to the conclusion that it is some KDE 2 interaction
with the X server that triggers this...
And that the OS - keyboard and video still runs.
I have seen data IO on modem after freeze...
(Thinking about trying another window manager for awhile...)
But every time I have had an opportunity to hook up another computer, like
tonight - It does not happen... :-(
/RogerL
On Monday 04 December 2000 22:27, Steven Cole wrote:
> If I have the cs46xx driver compiled either as a module or into
> the kernel, then 2.4.0-test12-pre4 locks up when KDE 2.0
> is started.
>
> The problem with dummy.o in 2.4.0-test12-pre4 allowed me
> to find the possible source of this lock-up which I have been
> seeing recently (since test11-ac2) while starting up KDE 2.0.
>
> This morning, I tried out 2.4.0-test12-pre4, and KDE 2.0
> started up (and there was much rejoicing). Of course, I
> saw the error when I tried to make modules, but I thought
> could live without sound for one bootup.
>
> Then I applied Mohammad A. Haque's small patch to
> linux/include/linux/module.h, recompiled , and the system
> froze again at the same spot ("Loading the panel")
> while starting up KDE 2.0.
>
> I found that if I said N for the cs46xx sound driver, then I
> get a 2.4.0-test12-pre4 kernel that will run KDE 2.0,
> sans sound :(.
>
> I can run GNOME with 2.4.0-test12-pre4 with
> cs46xx compiled as a module or compiled into the kernel,
> and everything works just fine.
>
> Here is some additional information from /var/log/messages:
> 2.4.0-test10 works OK with KDE 2.0 and sound.
>
> For 2.4.0-test12-pre4:
>
> Crystal 4280/461x + AC97 Audio, version 0.14, 13:39:25 Dec 4 2000
> cs461x: Card found at 0xf8ffe000 and 0xf8e0, IRQ 18
> cs461x: Unknown card (:) at 0xf8ffe000/0xf8e0, IRQ 18
> ac97_codec: AC97 Audio codec, id: 0x4352:0x5914 (Unknown)
>
> For 2.4.0-test10:
>
> Crystal 4280/461x + AC97 Audio, version 0.09, 15:31:37 Nov 1 2000
> cs461x: Card found at 0xf8ffe000 and 0xf8e0, IRQ 18
> cs461x: Unknown card (1028:0096) at 0xf8ffe000/0xf8e0, IRQ 18
> ac97_codec: AC97 Audio codec, id: 0x4352:0x5914 (Unknown)
>
> The hardware is a DELL 420 dual P-III.
> The base linux distro is Linux-Mandrake 7.2.
> Filesystems are ReiserFS, running reiserfs-3.6.19 for test12
> and reiserfs-3.6.18 for test10.
>
> Note: The ReiserFS folks looked at this, but could
> not reproduce this on another smp machine. That
> was before I noticed the connection with cs46xx.
>
> When I say the system freezes, I mean it completely locks up, and
> ALT-SYSRQ- does not do a thing. The magic
> key combo gives the expected result before freezup.
>
> Thanks in advance for any help,
>
> Steven
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
--
--
Home page:
http://www.norran.net/nra02596/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: aacraid for 2.4.0
On Mon, Dec 04, 2000 at 05:31:04PM -0500, Boerner, Brian wrote: > EIP:0010:[] > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010286 > eax: 0025 ebx: c881c000 ecx: edx: ^ > esi: 0001 edi: ebp: c88296a0 esp: c6b51e74 > ds: 0018 es: 0018 ss: 0018 > c0123180 > Call Trace: [] [] [] [] [] > [] [ 1>] >[] [] [] [] [] > [] [] [ > ] > Code: 00 00 00 00 00 00 00 00 b8 00 00 00 83 ec 34 68 00 2c 82 c8 ^^^ > Code; c881c054 <[aacraid]AAC_AnnounceDriver+0/8> <= > <_EIP>: <= It is jumping before the function AAC_DetectHostadapter, where there are 0 bytes. Two 0 bytes are "add %al,(%eax)" in x86. It is crashing because %eax does not contain a valid pointer (but 25). Now you just have to find out why you're jumping to the bogus pointer. It could e.g. be caused by a stack overwrite. Hope that helps, -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
NOSMP kernel option doesn't work
Hi
I would like to nosmp kernel option to be working again.
In my case (Bp6) machine gets frozed while
hda: 40088160 sectors (20525 MB) w/1961KiB Cache, CHS=2495/255/63,
UDMA(33)
hdf: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=59560/16/63,
UDMA(66)
Partition check:
/dev/ide/host0/bus0/target0/lun0: p1 p2 p3 < p5 p6 p7 p8 p9 >
/dev/ide/host2/bus0/target1/lun0: hdf: lost interrupt
this should be there [PTBL] [3737/255/63] p1 p2 p4 < p5 p6 p7 p8 p9 >
Also I would say there are some big trabbles which are higlly visible
when transferring files from ext2 to vfat partions from UDMA66 to UDMA33
disc - so I assume interrupt handling is not correct
(ok I know hpt366 is broken and bla bla bla, but)
--
There are three types of people in the world:
those who can count, and those who can't.
Zdenek Kabelac http://i.am/kabi/ [EMAIL PROTECTED] {debian.org; fi.muni.cz}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
aacraid for 2.4.0
Many of you, specifically customers of Dell Computer have been asking about the aacraid driver and the 2.4.0 kernel. Development is underway, however I have run into a stumbling block and am not sure how to proceed. The driver is generating a segmentation fault and produces and oops. I have included that for your viewing pleasure. From the output of ksymoops, it appears to be dying in AAC_AnnounceDriver. This plagues me because this function only does two things. One is print the name of the driver and the date it was built on. The other is call schedule(). Does anyone know why calling schedule in the 2.4.x stream would cause me heartache? I've put in a bunch of prints to see if I get past the announce routine, but I do not. Any ideas or pointers from more experienced 2.4 porters is greatly appreciated. I'm really cutting it down to the wire now. :-) -bmb- enomem.ntc.adaptec.com:bmb% more output.txt ksymoops 2.3.5 on i686 2.4.0-test11. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test11/ (default) -m ./linux-2.4.0-test11/System.map (specified) Unable to handle kernel NULL pointer dereference at virtual address 0025 c881c054 *pde = Oops: 0002 CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: 0025 ebx: c881c000 ecx: edx: esi: 0001 edi: ebp: c88296a0 esp: c6b51e74 ds: 0018 es: 0018 ss: 0018 Process insmod (pid: 711, stackpage=c6b51000) Stack: c881c07e 0001 c8822c00 c6bb6da0 c6bb66a0 c7f57260 c6b10150 c0120899 c6bb66a0 000c c6bb66a0 080545a0 c01a8bf8 c88296a0 080545a0 c6b10150 0014 c0123180 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [ ] Code: 00 00 00 00 00 00 00 00 b8 00 00 00 83 ec 34 68 00 2c 82 c8 >>EIP; c881c054 <[aacraid]AAC_AnnounceDriver+0/8> <= Trace; c881c07e <[aacraid]AAC_DetectHostAdapter+22/3d8> Trace; c8822c00 <[aacraid].rodata.start+440/32fc> Trace; c0120899 Trace; c01a8bf8 Trace; c88296a0 <[aacraid]driver_template+0/6c> Trace; c0123180 Trace; c0123451 Trace; c881c000 <_end+852054c/85205a0> Trace; c881cb85 <[aacraid]init_this_scsi_driver+19/44> Trace; c88296a0 <[aacraid]driver_template+0/6c> Trace; c88296a0 <[aacraid]driver_template+0/6c> Trace; c881c000 <_end+852054c/85205a0> Trace; c0118c65 Trace; c881c060 <[aacraid]AAC_DetectHostAdapter+4/3d8> Trace; c0108f77 Code; c881c054 <[aacraid]AAC_AnnounceDriver+0/8> <= <_EIP>: <= Code; c881c05c <[aacraid]AAC_DetectHostAdapter+0/3d8> 8: b8 00 00 00 83mov$0x8300,%eax Code; c881c061 <[aacraid]AAC_DetectHostAdapter+5/3d8> d: ecin (%dx),%al Code; c881c062 <[aacraid]AAC_DetectHostAdapter+6/3d8> e: 34 68 xor$0x68,%al Code; c881c064 <[aacraid]AAC_DetectHostAdapter+8/3d8> 10: 00 2c 82 add%ch,(%edx,%eax,4) Code; c881c067 <[aacraid]AAC_DetectHostAdapter+b/3d8> 13: c8 00 00 00 enter $0x0,$0x0 enomem.ntc.adaptec.com:bmb% Brian M. Boerner System Software Developer Adaptec, Inc. Nashua, NH 03060 (603) 579-4625 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test12pre4: parport / lp problems
In <[EMAIL PROTECTED]> Henrik Størner <[EMAIL PROTECTED]> writes: >I discovered yesterday that printing does not work in 2.4.0-test12-pre4. OK - mea culpa. It turned out to be a configuration problem: I had been playing with the I2C support for lm_sensors, and in my attempt to get it working I had apparently enabled an I2C driver that grabbed the parport0 device before lp could get at it. After turning off the I2C support, my printer is working again. Sorry for the false alarm. Henrik -- Henrik Storner | "Crackers thrive on code secrecy. Cockcroaches breed <[EMAIL PROTECTED]> | in the dark. It's time to let the sunlight in." | | Eric S. Raymond, re. the Frontpage backdoor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Using map_user_kiobuf()
Hi,
On Thu, Nov 30, 2000 at 01:07:37PM -, John Meikle wrote:
> I have been experimenting with a module that returns data to either a user
> space programme or another module. A memory area is passed in, and the data
> is written to it. Because the memory may be allocated either by a module or
> a user programme, a kiobuf seemed a good way of representing it. A layer
> converts user memory to a kiobuf using map_user_kiobuf().
There are a number of fixes pending for 2.4, and released for 2.2, but
nothing that would explain the sort of kernel corruption you are
reporting --- it sounds as if you are overrunning the end of the
kiobuf, but it's hard to know without seeing the real code.
> The code in the module (without validation and error checking) is:
>
> int test_kiobuf(char* buf)
> {
> struct kiobuf *iobuf;
> int i;
>
> alloc_kiovec(1, );
> map_user_kiobuf(WRITE, iobuf, buf, TEST_SIZE);
Careful, you can't touch the buffer for a WRITE map. The READ/WRITE
flag is from the point of view of the user, and user write() syscalls
don't touch the data in memory! If you want to modify the user
buffer, you need to use READ instead.
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test12-pre4 + cs46xx + KDE 2.0 = frozen system
On Mon, 4 Dec 2000 14:27:10 -0700, Steven Cole <[EMAIL PROTECTED]> wrote: >If I have the cs46xx driver compiled either as a module or into >the kernel, then 2.4.0-test12-pre4 locks up when KDE 2.0 >is started. >[snip] >When I say the system freezes, I mean it completely locks up, and >ALT-SYSRQ- does not do a thing. The magic >key combo gives the expected result before freezup. Try the kdb patch, it is very good at getting data out when a machine has hung. You will need a serial console to see kdb output, it does not work with X. ftp://oss.sgi.com/projects/kdb/download/ix86/ kdb-v1.6-2.4.0-test11-pre7.gz should still fit 2.4.0-test12-pre4. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11
Agreed. I've got one of these beasts running NT Server, dual 433 non o/c, 4x12.7 gig software raid. Before i put the Promise Ultra/33 card in, i was using the HPT366. Random lockups every couple weeks. Stopped using the HPT366, machine is stable now. In hindsight, I think the HPT366 was the cause of the Onstream 50 gig drive that locked up frequently too, before i shipped that back to Onstream. One thing that did help on stability was putting a cpu fan on the chipset. Dan Hollis wrote: > > Your 1 success out of maybe 500-1000 peoples failures. Not exactly a great > average for this motherboard. BP6 is notorious for instability, HPT366 on > it is about 50% of the problems. > > -Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test12-pre4 boot failure (better than pre3 and lower)
On Mon, 4 Dec 2000 16:26:42 -0500,
Wakko Warner <[EMAIL PROTECTED]> wrote:
>PCI patches that were added between pre3 and pre4 allow me to boot the
>kernel on my noritake alpha. Once it boots, however, it oops's in the
>swapper. I've tried a few times in the past to use ksymoops on oops's on
>the alpha arch, but it doesn't appear to work. (I'm using the ksymoops
>that's part of the debian potato dist)
Most architectures dump their code as a string of bytes and print the
code after the registers and trace back. Alpha dumps the code before
the trace and also decodes the instructions which really confuses
ksymoops. Somebody changed 'Trace: ' to 'Trace:' between 2.2 and 2.4
kernels so ksymoops no longer picks the trace data.
Is there any chance of changing arch/alpha/kernel/traps.c to print
registers, trace and _raw_ code, in that order so it is more like other
architectures? You can print the decoded instructions as well (prefix
Decode:, not Code:) as long as the raw code bytes are also available.
In the meantime, this patch to ksymoops 2.3.5 will pick up the change
to the trace lines. It will still complain about a bad code line,
ksymoops is built for raw data.
Index: 6.2/oops.c
--- 6.2/oops.c Mon, 06 Nov 2000 16:34:56 +1100 kaos (ksymoops-2.3/11_oops.c 1.22 644)
+++ 6.2(w)/oops.c Tue, 05 Dec 2000 08:37:38 +1100 kaos (ksymoops-2.3/11_oops.c 1.22
+644)
@@ -1081,7 +1081,7 @@ static const char *Oops_trace(const char
RE_COMPILE(_Oops_trace,
"^(" /* 1 */
"(Call Trace: )" /* 2 */
-/* alpha */ "|(Trace: )"/* 3 */
+/* alpha */ "|(Trace:)" /* 3 */
/* various */ "|(" BRACKETED_ADDRESS ")" /* 4,5 */
/* ppc */ "|(Call backtrace:)" /* 6 */
/* ppc, s390 */ "|" UNBRACKETED_ADDRESS /* 7 */
@@ -1464,7 +1464,7 @@ static int Oops_print(const char *line,
* anybody wants to print a VERSION_ line in their Oops, this code
* is ready.
*
- * string 9 is defined if the text is 'Trace: ' (alpha).
+ * string 9 is defined if the text is 'Trace:' (alpha).
* string 10 is defined if the text is 'Call backtrace:' (ppc, i370).
* string 11 is defined if the text is 'bh:' (i386). Stack addresses are
* on the next line. In our typical inconsistent manner, the bh: stack
@@ -1503,7 +1503,7 @@ static int Oops_print(const char *line,
/* various */ "|(Call Trace: )" /* 5 T */
/* various */ "|(" BRACKETED_ADDRESS ")" /* 6,7 T */
/* various */ "|(Version_[0-9]+)"/* 8 */
-/* alpha */"|(Trace: )"/* 9 T */
+/* alpha */"|(Trace:)" /* 9 T */
/* ppc, i370 */ "|(Call backtrace:)" /* 10 T */
/* i386 */ "|(bh:)"/* 11 T */
/* i386 */ "|" REVBRACKETED_ADDRESS/* 12 T */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11
On Mon, 4 Dec 2000, Richard Torkar wrote: > Dan Hollis wrote: > > On Tue, 5 Dec 2000, Gerard Sharp wrote: > > > Gnea wrote: > > > > > [1.] One line summary of the problem: > > > > > Intermittent corruption of 4 bytes in SMP kernels using HPT366 > > > > [snip] > > > > Have you tried updating the bios on the bp6? This solved a LOT of > > > > problems for me, and afaik, ru is the latest... > > > RU seems the latest. Flashed bios as per your nicely detailed > > > instructions. > > > No improvement in condition, alas. > > HPT366 on BP6 is just broken. Corruption and lockups happen under > > microsoft-windoze as well. > Not my experience Dan. > I've used my BP6 + HPT366 for a while now and I haven't had on lockup. > No corruption either. > I guess I'm lucky *grin* Your 1 success out of maybe 500-1000 peoples failures. Not exactly a great average for this motherboard. BP6 is notorious for instability, HPT366 on it is about 50% of the problems. -Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kernel panic in SoftwareRAID autodetection
On 01-Dec-00, Neil Brown wrote: > On Friday December 1, [EMAIL PROTECTED] wrote: >> I found a real showstopper problem in the SoftwareRAID autodetect >> code; 2.4.0-test10 and 2.4.0-test11 are affected (I didn't test >> previous versions). [detailed report] > > Fixed in 2.4.0-test12pre3. I tried 2.4.0-test12pre3. The problem is *not* fixed: kernel panic again. Please CC to me because I'm not a LKML subscriber. -- Roberto Ragusa robertoragusa at technologist.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dan Hollis wrote: > On Tue, 5 Dec 2000, Gerard Sharp wrote: > > Gnea wrote: > > > > [1.] One line summary of the problem: > > > > Intermittent corruption of 4 bytes in SMP kernels using HPT366 > > > [snip] > > > Have you tried updating the bios on the bp6? This solved a LOT of > > > problems for me, and afaik, ru is the latest... > > RU seems the latest. Flashed bios as per your nicely detailed > > instructions. > > No improvement in condition, alas. > > HPT366 on BP6 is just broken. Corruption and lockups happen under > microsoft-windoze as well. > Not my experience Dan. I've used my BP6 + HPT366 for a while now and I haven't had on lockup. No corruption either. Presently I use 2.4.0-test11-p4 and I have been following the 2.3.* kernel since the day I got the BP6. I have two Celeron 500 which are *not* o/c. I have seti@home running on this box 24/7. I use the latest BIOS. I guess I'm lucky *grin* /Richard -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6LAwsUSLExYo23RsRAtY+AKCOuqpfcSa73zzpHQfddSY/7JG8IACffPRe UzfNUJ7t3y2jdsS4jmS4Ggg= =FdqO -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test12-pre4 + cs46xx + KDE 2.0 = frozen system
If I have the cs46xx driver compiled either as a module or into
the kernel, then 2.4.0-test12-pre4 locks up when KDE 2.0
is started.
The problem with dummy.o in 2.4.0-test12-pre4 allowed me
to find the possible source of this lock-up which I have been
seeing recently (since test11-ac2) while starting up KDE 2.0.
This morning, I tried out 2.4.0-test12-pre4, and KDE 2.0
started up (and there was much rejoicing). Of course, I
saw the error when I tried to make modules, but I thought
could live without sound for one bootup.
Then I applied Mohammad A. Haque's small patch to
linux/include/linux/module.h, recompiled , and the system
froze again at the same spot ("Loading the panel")
while starting up KDE 2.0.
I found that if I said N for the cs46xx sound driver, then I
get a 2.4.0-test12-pre4 kernel that will run KDE 2.0,
sans sound :(.
I can run GNOME with 2.4.0-test12-pre4 with
cs46xx compiled as a module or compiled into the kernel,
and everything works just fine.
Here is some additional information from /var/log/messages:
2.4.0-test10 works OK with KDE 2.0 and sound.
For 2.4.0-test12-pre4:
Crystal 4280/461x + AC97 Audio, version 0.14, 13:39:25 Dec 4 2000
cs461x: Card found at 0xf8ffe000 and 0xf8e0, IRQ 18
cs461x: Unknown card (:) at 0xf8ffe000/0xf8e0, IRQ 18
ac97_codec: AC97 Audio codec, id: 0x4352:0x5914 (Unknown)
For 2.4.0-test10:
Crystal 4280/461x + AC97 Audio, version 0.09, 15:31:37 Nov 1 2000
cs461x: Card found at 0xf8ffe000 and 0xf8e0, IRQ 18
cs461x: Unknown card (1028:0096) at 0xf8ffe000/0xf8e0, IRQ 18
ac97_codec: AC97 Audio codec, id: 0x4352:0x5914 (Unknown)
The hardware is a DELL 420 dual P-III.
The base linux distro is Linux-Mandrake 7.2.
Filesystems are ReiserFS, running reiserfs-3.6.19 for test12
and reiserfs-3.6.18 for test10.
Note: The ReiserFS folks looked at this, but could
not reproduce this on another smp machine. That
was before I noticed the connection with cs46xx.
When I say the system freezes, I mean it completely locks up, and
ALT-SYSRQ- does not do a thing. The magic
key combo gives the expected result before freezup.
Thanks in advance for any help,
Steven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test12-pre4 boot failure (better than pre3 and lower)
PCI patches that were added between pre3 and pre4 allow me to boot the kernel on my noritake alpha. Once it boots, however, it oops's in the swapper. I've tried a few times in the past to use ksymoops on oops's on the alpha arch, but it doesn't appear to work. (I'm using the ksymoops that's part of the debian potato dist) I have attached the boot log. Keep my name in the CC -- Lab tests show that use of micro$oft causes cancer in lab animals Linux version 2.4.0-test12-pre4 (wakko@kakarot) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #2 Mon Dec 4 09:07:20 EST 2000 Booting on Noritake using machine vector Noritake from SRM Command line: root=/dev/sda1 ro single console=ttyS0 memcluster 0, usage 1, start0, end 171 memcluster 1, usage 0, start 171, end20403 memcluster 2, usage 1, start20403, end20480 freeing pages 171:384 freeing pages 625:20403 On node 0 totalpages: 20480 zone(0): 20480 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/sda1 ro single console=ttyS0 Using epoch = 1900 Console: colour VGA+ 80x25 Calibrating delay loop... 525.34 BogoMIPS Memory: 157168k/163224k available (1114k kernel code, 4688k reserved, 241k data, 208k init) Dentry-cache hash table entries: 32768 (order: 6, 524288 bytes) Buffer-cache hash table entries: 8192 (order: 3, 65536 bytes) Page-cache hash table entries: 32768 (order: 5, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 262144 bytes) POSIX conformance testing by UNIFIX got res[280:2ff] for resource 1 of 3DLabs Permedia II 2D+3D got res[300:37f] for resource 2 of 3DLabs Permedia II 2D+3D got res[220:221] for resource 0 of 3DLabs Permedia II 2D+3D got res[222:222] for resource 6 of 3DLabs Permedia II 2D+3D got res[9000:90ff] for resource 0 of Q Logic ISP1020 got res[9400:947f] for resource 0 of Digital Equipment Corporation DECchip 21142/43 got res[9480:94bf] for resource 0 of 3Com Corporation 3c905 100BaseTX [Boomerang] got res[380:383] for resource 6 of Digital Equipment Corporation DECchip 21142/43 got res[384:384] for resource 6 of Q Logic ISP1020 got res[385:385] for resource 6 of 3Com Corporation 3c905 100BaseTX [Boomerang] got res[386:3860fff] for resource 1 of Q Logic ISP1020 got res[3861000:386107f] for resource 1 of Digital Equipment Corporation DECchip 21142/43 PCI: Bus 1, bridge: Digital Equipment Corporation DECchip 21050 IO window: 1000-9fff MEM window: 0380-038f PCI enable device: (Intel Corporation 82375EB) cmd reg 0x7 PCI enable device: (Digital Equipment Corporation DECchip 21050) cmd reg 0x107 PCI enable device: (3DLabs Permedia II 2D+3D) cmd reg 0x7 PCI enable device: (Q Logic ISP1020) cmd reg 0x47 PCI enable device: (Digital Equipment Corporation DECchip 21142/43) cmd reg 0x47 PCI enable device: (3Com Corporation 3c905 100BaseTX [Boomerang]) cmd reg 0x47 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A ttyS03 at 0x02e8 (irq = 3) is a 16550A SCSI subsystem driver Revision: 1.00 qlogicisp : new isp1020 revision ID (2) scsi0 : QLogic ISP1020 SCSI on PCI bus 01 device 00 irq 17 I/O base 0x9000 Vendor: WDIGTLModel: ENTERPRISERev: 1.80 Type: Direct-Access ANSI SCSI revision: 02 Vendor: DEC Model: RZ28D(C) DEC Rev: 0010 Type: Direct-Access ANSI SCSI revision: 02 Vendor: DEC Model: RZ28D(C) DEC Rev: 0008 Type: Direct-Access ANSI SCSI revision: 02 Vendor: DEC Model: RZ28D(C) DEC Rev: 0008 Type: Direct-Access ANSI SCSI revision: 02 Vendor: ARCHIVE Model: Python 25501-XXX Rev: 2.54 Type: Sequential-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 Detected scsi disk sdb at scsi0, channel 0, id 1, lun 0 Detected scsi disk sdc at scsi0, channel 0, id 2, lun 0 Detected scsi disk sdd at scsi0, channel 0, id 3, lun 0 SCSI device sda: 4254819 512-byte hdwr sectors (2178 MB) Partition check: sda: sda1 sda2 sda3 sda4 sda5 SCSI device sdb: 4110480 512-byte hdwr sectors (2105 MB) sdb: unknown partition table SCSI device sdc: 4110480 512-byte hdwr sectors (2105 MB) sdc: unknown partition table SCSI device sdd: 4110480 512-byte hdwr sectors (2105 MB) sdd: unknown partition table NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 1024 buckets, 16Kbytes TCP: Hash tables configured (established 16384 bind 16384) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 208k freed Unable to handle kernel
Re: multiprocessor kernel problem
Rusty,
Excellent! I applied the patch and netfilter is happy with 4 processors. Thank you
and
thanks to everyone else who sent suggestions.
Roger
Rusty Russell wrote:
> In message <[EMAIL PROTECTED]> you write:
> > yes, but is it a dual machine or is it an N-way SMP with N > 2? the
> > other guy with iptables/SMP problems also has a quad box. could this
> > perhaps be a problem only when you have more than two processors?
>
> Yes, hacked my machine to think it had 4 cpus, and boom.
>
> There are two problems:
> (1) initialization of multiple tables was wrong, and
> (2) iterating through tables should not use cpu_number_map (doesn't
> matter on X86 though).
>
> Please try attached patch.
>
> Thanks,
> Rusty,
> --
> Hacking time.
> --- working-2.4.0-test11-5/net/ipv4/netfilter/ip_tables.c.~1~ Sat Aug 12 00:23:40
>2000
> +++ working-2.4.0-test11-5/net/ipv4/netfilter/ip_tables.c Mon Dec 4 16:12:44
>2000
> @@ -89,10 +89,8 @@
> unsigned int hook_entry[NF_IP_NUMHOOKS];
> unsigned int underflow[NF_IP_NUMHOOKS];
>
> - char padding[SMP_ALIGN((NF_IP_NUMHOOKS*2+2)*sizeof(unsigned int))];
> -
> /* ipt_entry tables: one per CPU */
> - char entries[0];
> + char entries[0] __attribute__((aligned(SMP_CACHE_BYTES)));
> };
>
> static LIST_HEAD(ipt_target);
> @@ -101,7 +99,7 @@
> #define ADD_COUNTER(c,b,p) do { (c).bcnt += (b); (c).pcnt += (p); } while(0)
>
> #ifdef CONFIG_SMP
> -#define TABLE_OFFSET(t,p) (SMP_ALIGN((t)->size)*cpu_number_map(p))
> +#define TABLE_OFFSET(t,p) (SMP_ALIGN((t)->size)*(p))
> #else
> #define TABLE_OFFSET(t,p) 0
> #endif
> @@ -283,7 +281,8 @@
> read_lock_bh(>lock);
> IP_NF_ASSERT(table->valid_hooks & (1 << hook));
> table_base = (void *)table->private->entries
> - + TABLE_OFFSET(table->private, smp_processor_id());
> + + TABLE_OFFSET(table->private,
> + cpu_number_map(smp_processor_id()));
> e = get_entry(table_base, table->private->hook_entry[hook]);
>
> #ifdef CONFIG_NETFILTER_DEBUG
> @@ -860,7 +859,7 @@
>
> /* And one copy for every other CPU */
> for (i = 1; i < smp_num_cpus; i++) {
> - memcpy(newinfo->entries + SMP_ALIGN(newinfo->size*i),
> + memcpy(newinfo->entries + SMP_ALIGN(newinfo->size)*i,
>newinfo->entries,
>SMP_ALIGN(newinfo->size));
> }
> @@ -1359,7 +1358,7 @@
> int ret;
> struct ipt_table_info *newinfo;
> static struct ipt_table_info bootstrap
> - = { 0, 0, { 0 }, { 0 }, { }, { } };
> + = { 0, 0, { 0 }, { 0 }, { } };
>
> MOD_INC_USE_COUNT;
> newinfo = vmalloc(sizeof(struct ipt_table_info)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
New patches for 2.2.18pre24 raw IO (fix for bounce buffer copy)
Hi,
I have pushed another set of raw IO patches out, this time to fix a
bug with bounce buffer copying when running on highmem boxes. It is
likely to affect any bounce buffer copies using non-page-aligned
accesses if both highmem and normal pages are involved in the kiobuf.
The specific new patch added in this patchset is attached below. The
full set has been uploaded as
kiobuf-2.2.18pre24-B.tar.gz
at
ftp.*.kernel.org:/pub/linux/kernel/people/sct/raw-io/
and ftp.uk.linux.org:/pub/linux/sct/fs/raw-io/
This one really should kill all known bugs, dead. Please stress it
out and let me know if anybody encounters any further problems. A
merge of all of the pending raw IO fixes into 2.4 should be happening
soon once the current VM changes for marking pages dirty are working.
Cheers,
Stephen
--- linux-2.2.18pre24.raw.bigmem/fs/iobuf.c.~1~ Mon Dec 4 20:13:49 2000
+++ linux-2.2.18pre24.raw.bigmem/fs/iobuf.c Mon Dec 4 20:14:08 2000
@@ -211,10 +211,10 @@
unsigned long kin, kout;
int pagelen = length;
+ if ((pagelen+offset) > PAGE_SIZE)
+ pagelen = PAGE_SIZE - offset;
+
if (bounce_page) {
- if ((pagelen+offset) > PAGE_SIZE)
- pagelen = PAGE_SIZE - offset;
-
if (direction == COPY_TO_BOUNCE) {
kin = kmap(page, KM_READ);
kout = kmap(bounce_page, KM_WRITE);
Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11
On Tue, 5 Dec 2000, Gerard Sharp wrote: > Gnea wrote: > > > [1.] One line summary of the problem: > > > Intermittent corruption of 4 bytes in SMP kernels using HPT366 > > [snip] > > Have you tried updating the bios on the bp6? This solved a LOT of > > problems for me, and afaik, ru is the latest... > RU seems the latest. Flashed bios as per your nicely detailed > instructions. > No improvement in condition, alas. HPT366 on BP6 is just broken. Corruption and lockups happen under microsoft-windoze as well. -Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test12pre4: parport / lp problems
I discovered yesterday that printing does not work in 2.4.0-test12-pre4. This is a pretty stock PC system with a printer on the parallel port. Both parport and lp is compiled into the kernel - and the parport appears to be detected OK, but the lp driver for some reason refuses to use it: [snip /var/log/dmesg] Starting kswapd v1.8 parport0: PC-style at 0x378 [PCSPP] parport0: irq 7 detected [later] pty: 256 Unix98 ptys configured parport0: no more devices allowed lp: driver loaded but no devices found In lilo, I have tried different configuration parameters. The current setup has no parport or lp settings, but I have also tried "parport=0x378,7 lp=parport0" with no apparent effect. This setting used to work in earlier 2.4 configurations (cannot say exactly which worked and which didn't). Kernel config: # # Parallel port support # CONFIG_PARPORT=y CONFIG_PARPORT_PC=y CONFIG_PARPORT_PC_FIFO=y # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set # CONFIG_PARPORT_1284 is not set [snip] CONFIG_PRINTER=y # CONFIG_LP_CONSOLE is not set # CONFIG_PPDEV is not set Suggestions ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
autoloading of lowlevel modules broken (devfs-related?)
Hi there, I've had some strange problems with autoloading of some modules in the latest versions of the kernel (up to test12-pre4). I'm using devfs and modutils 2.3.21. Most of the modules autoload fine however ppp_async and parport_pc don't autoload anymore. /etc/modules.conf has the following aliases: alias char-major-108 ppp_generic alias tty-ldisc-3ppp_async alias parport_lowlevel parport_pc Everything worked fine with that setup until 2.4.0-test8. If I insmod the modules by hand things continue to run smoothly. Is there an obvious problem that I have missed? Does anybody else have these problems? Can anybody help me? Thanks a lot in advance... Felix PS: please cc me directly -- Felix Braun 1910 rue Wellington Montreal PQ Canada H3K 1W3 Tel: ++1-514-933 60 58 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Attempt to hard link across filesystems results inun-unmountable filesystem (fwd)
On Mon, 4 Dec 2000, Alexander Viro wrote: > Tigran, think about the uses from knfsd. Yes, you are right. I thought I grepped for all usages of vfs_link but looks like I did not, i.e. when sending the patch I was sure that sys_link is the only user of vfs_link but now that you pointed it out I clearly see why my suggestion was wrong. Thank you, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Attempt to hard link across filesystems results inun-unmountable filesystem (fwd)
Yo Tigran! On Mon, 4 Dec 2000, Tigran Aivazian wrote: > Second attempt, the first one failed due to stupid setup of ISP and the > usage of mail-abuse.org which blocks anything that has no reverse DNS > lookup. Mail-abuse.org does nothing with reverse DNS.Many that hate spam choose to refuse mail with no reverse DNS on theire own. RGDS GARY --- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Attempt to hard link across filesystems results inun-unmountable filesystem (fwd)
On Mon, 4 Dec 2000, Tigran Aivazian wrote: > It is true that your patch fixes the problem as reported but let us look > one step deeper into the problem. Linux supports multiply mounted > instances of a filesystem and the check in sys_link() comparing the > mountpoints would refuse (with cross-device link error) linking between > them. This is correct. However, one level down, inside vfs_link() we also > check for ->i_dev match and that seems unnecessary, now that (with your > patch) link(2) would work correctly anyway. > > Therefore, I propose a slightly modified (tested under > 2.4.0-test12-pre4) version of the patch. What do you think? My philosophy > is -- since you made this feature work properly you should make it work > efficiently too and that means removing redundant code. Tigran, think about the uses from knfsd. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DMA !NOT ONLY! for triton again...
Well, i just checked ide-dma.c, and the WDC 21600 isn't listed. 31600 is, but no 21600 I've been using the 21600 for awhile now with DMA enabled, under reasonable load, and it seems to hold up. Guennadi: I don't suppose you can get your hands on a different size/brand drive long enough to plug it in, and see if it allows DMA? Alan Cox wrote: > Certain older WDC drives are explicitly blacklisted due to firmware bugs. > WDC put out firmware upgrades but given no answer from them on how to be sure > a drive was upgraded we play safe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] inode dirty blocks Re: test12-pre4
On Mon, 4 Dec 2000, Stephen C. Tweedie wrote: > Agreed. However, is there any reason to have this as a separate > function? bforget() should _always_ remove the buffer from any inode > queue. You can make that operation conditional on (bh->b_inode != > NULL) if you want to avoid taking the lru lock unnecessarily. I doubt it. bforget() is called, for example, when we deal with the changed branch in ext2_get_block() (the thing had been partially read, but then we've noticed that it had been changed under us). And I don't think that brelse() would be a good thing there... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: *_trylock return on success?
So what is a coder to do. We need to define the pi_mutex_trylock(). If I understand this thread, it should return 0 on success. Is this correct? George On Saturday 25 November 2000 22:05, Roger Larsson wrote: > On Saturday 25 November 2000 20:22, Philipp Rumpf wrote: > > On Sat, Nov 25, 2000 at 08:03:49PM +0100, Roger Larsson wrote: > > > > _trylock functions return 0 for success. > > > > > > Not spin_trylock > > > > Argh, I missed the (recent ?) change to make x86 spinlocks use 1 to mean > > unlocked. You're correct, and obviously this should be fixed. Have looked more into this now... tasklet_trylock is also wrong (but there are only four of them) Is this 2.4 only, or where there spin locks earlier too? My suggestion now is a few steps: 1) to release a kernel version that has corrected _trylocks; spin2_trylock and tasklet2_trylock. [with corresponding updates in as many places as possible: s/!spin_trylock/spin2_trylock/g s/spin_trylock/!spin2_trylock/g . . .] (ready for spin trylock, not done for tasklet yet..., attached, hope it got included OK - not fully used to kmail) 2) This will in house only drives or compilations that in some strange way uses this calls... 3a) (DANGEROUS) global rename spin2_trylock to spin_trylock [no logic change this time - only name] 3b) (dangerous) add compatibility interface #define spin_trylock(L) (!spin2_trylock(L)) Probably not necessary since it can not be linked against. Binary modules will contain their own compatibility code :-) Probably preferred by those who maintain drivers for several releases; 2.2, 2.4, ... 3c) do not do anything more... Alternative: 1b) do nothing at all - suffer later /RogerL - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Summary: lost dirs after fsck (also via82cxx works on kt133)
In-Reply-To: <[EMAIL PROTECTED]> Thanks for the replies. As for why I ran the devel kernel with important data, I made the fatal mistake of listening: Me: "Are you sure it will be ok??!?" Friend: "No problems. It's rock solid. I've been running it for weeks." The fact that he also overclocks his cpu 300 Mhz should have been a thermonucleur warning sign. On a side note, the linux2.4-test10+ via82cxxx (ac97 codec) works nicely on the kt133 mobo whereas it locks the machine in linux2.2. Only unusual thing I noticed is that it pauses a few seconds before letting me change the volume. --- data recovery --- Roger Wolff mentioned: "Harddisk-recovery.com" is a professional data-recovery service. If you put the drive in a Linux system with LOTs of extra disk space, we can even try to recover your data remotely over the internet. The costs are 1195 euro per recovery, plus 0.50 euro per recovered Mb of data. Barry K. Nathan & Theodore Y. Ts'o reminded me to look in lost+found and Ted said the URLs were a good place to start. Sorry I was kinda vague on the details of the corruption (I lost all my scrollback logs). It did not happen after a crash. I was noticing weird errors after mounting the drive from a different OS (I think group inode errors?), so I blindly ran fsck -y on it. Unfortunately it's a 61 gig 5400 rpm drive, so a plaintext string search on the partition has been running about two days so far. debugfs hasn't been helpful so far altho I haven't reviewed the lsdel inodes yet. I think at this point I'm going to just save the hd for rainy days/weeks. Thanks again. Saber _ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Nightly usb oops
Hi, What kernel (test10)? > -m /boot/System.map-2.4.0-test10 (specified) What compiler/version? Please post a list of your USB devices from /proc/bus/usb/devices . Are you inserting or unplugging a USB device when this happens? If not, are you doing anything with USB when this happens? Thanks, ~Randy_ |randy.dunlap_at_intel.com503-677-5408| |NOTE: Any views presented here are mine alone| |& may not represent the views of my employer.| --- > -Original Message- > From: J. Nick Koston [mailto:[EMAIL PROTECTED]] > Sent: Monday, December 04, 2000 7:13 AM > To: [EMAIL PROTECTED] > Subject: Nightly usb oops > > > My machine crashes almost every night with this oops. I've finally > managed to catch it before it was totally gone. > > > ksymoops 2.3.4 on i686 2.4.0-test10. Options used > -V (default) > -k /proc/ksyms (default) > -l /proc/modules (default) > -o /lib/modules/2.4.0-test10 (specified) > -m /boot/System.map-2.4.0-test10 (specified) > > Warning (compare_maps): snd symbol pm_register not found in > /lib/modules/2.4.0-test10/misc/snd.o. Ignoring > /lib/modules/2.4.0-test10/misc/snd.o entry > Warning (compare_maps): snd symbol pm_send not found in > /lib/modules/2.4.0-test10/misc/snd.o. Ignoring > /lib/modules/2.4.0-test10/misc/snd.o entry > Warning (compare_maps): snd symbol pm_unregister not found in > /lib/modules/2.4.0-test10/misc/snd.o. Ignoring > /lib/modules/2.4.0-test10/misc/snd.o entry > 0fef3340 e0 Stalled CRC/Timeo Length=7 MaxLen=7 DT0 > EndPt=0 Dev=1b, PID=2d(SETUP) (buf=0bd41580) ... (many STALL/CRC/Timeouts for Dev=1b, 22, 25) ... > Unable to handle kernel NULL pointer dereference at virtual > address 0014 > c01faed6 > *pde = > Oops: > CPU:0 > EIP:0010:[] > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010282 > eax: 0008 ebx: cbd41385 ecx: cbd41380 edx: 0008 > esi: edi: cfe12400 ebp: 0001 esp: c14fdf0c > ds: 0018 es: 0018 ss: 0018 > Process khubd (pid: 7, stackpage=c14fd000) > Stack: cbd41385 cfe12400 0001 0008 > 0009 >0001 c01fb1f3 cfe12400 > cfe12400 c5985802 >cfe12400 cbd41380 cbd41380 c01fb7f1 cfe12400 > 0001 > Call Trace: [] [] [] > [] [] [] [] >[] [] > Code: 8b 42 0c c7 44 24 24 00 00 00 00 0f b6 72 04 39 74 24 24 0f > > >>EIP; c01faed6<= > Trace; c01fb1f3 > Trace; c01fb7f1 > Trace; c01fcc60 > Trace; c01fce32 > Trace; c0293580 > Trace; c0293647 > Trace; c01fcfa5 > Trace; c0105000 > Trace; c0108c03 > Code; c01faed6 > <_EIP>: > Code; c01faed6<= >0: 8b 42 0c mov0xc(%edx),%eax <= > Code; c01faed9 >3: c7 44 24 24 00 00 00 movl $0x0,0x24(%esp,1) > Code; c01faee0 >a: 00 > Code; c01faee1 >b: 0f b6 72 04 movzbl 0x4(%edx),%esi > Code; c01faee5 >f: 39 74 24 24 cmp%esi,0x24(%esp,1) > Code; c01faee9 > 13: 0f 00 00 sldt (%eax) > > Unable to handle kernel NULL pointer dereference at virtual > address 0008 > c013ed99 > *pde = > Oops: > CPU:0 > EIP:0010:[] > EFLAGS: 00010246 > eax: 0008 ebx: ecx: 000c edx: 0002 > esi: edi: ebp: 0008 esp: c36f3f08 > ds: 0018 es: 0018 ss: 0018 > Process initlog (pid: 532, stackpage=c36f3000) > Stack: c36f2000 0002 000c 000e > c013eec3 0002 >0008 c36f3f48 c36f3f4c c36f2000 0002 0002 > c36f2000 > c013f133 0002 0002 > cbd41140 c36f3fb8 > Call Trace: [] [] [] [] > Code: 8b 45 00 85 c0 7c 59 e8 6b 1f ff ff 89 c6 bb 20 00 00 00 85 > > >>EIP; c013ed99<= > Trace; c013eec3 > Trace; c013f133 > Trace; c01203ed > Trace; c010a637 > Code; c013ed99 > <_EIP>: > Code; c013ed99<= >0: 8b 45 00 mov0x0(%ebp),%eax <= > Code; c013ed9c >3: 85 c0 test %eax,%eax > Code; c013ed9e >5: 7c 59 jl 60 <_EIP+0x60> > c013edf9 > Code; c013eda0 >7: e8 6b 1f ff ffcall 1f77 > <_EIP+0x1f77> c0130d10 > Code; c013eda5 >c: 89 c6 mov%eax,%esi > Code; c013eda7 >e: bb 20 00 00 00mov$0x20,%ebx > Code; c013edac > 13: 85 00 test %eax,(%eax) > > Unable to handle kernel NULL pointer dereference at virtual > address 0040 > c013ed99 > *pde = > Oops: > CPU:0 > EIP:0010:[] > EFLAGS: 00210246 > eax: 0040 ebx: ecx: 0044 edx: 0006 > esi: edi: ebp: 0040 esp: c09a7f08 > ds: 0018 es:
Re: Alpha SCSI error on 2.4.0-test11
Ivan, I've recompiled as you have suggested. Any ideas? Here is my dmesg output: Linux version 2.4.0-test12 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #3 Mon Dec 4 02:38:18 EST 2000 Booting GENERIC on Miata using machine vector Miata from SRM Command line: console=tty0 console=ttyS0,9600 root=/dev/fd0 memcluster 0, usage 1, start0, end 236 memcluster 1, usage 0, start 236, end 147455 memcluster 2, usage 1, start 147455, end 147456 freeing pages 236:384 freeing pages 754:147455 pci: cia revision 1 (pyxis) On node 0 totalpages: 147456 zone(0): 147456 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: console=tty0 console=ttyS0,9600 root=/dev/fd0 Using epoch = 1952 Console: colour VGA+ 80x25 Calibrating delay loop... 1191.18 BogoMIPS Memory: 1155136k/1179640k available (1602k kernel code, 22616k reserved, 515k data, 376k init) Dentry-cache hash table entries: 262144 (order: 9, 4194304 bytes) Buffer-cache hash table entries: 65536 (order: 6, 524288 bytes) Page-cache hash table entries: 262144 (order: 8, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 2097152 bytes) POSIX conformance testing by UNIFIX pci: passed tb register update test pci: passed sg loopback i/o read test pci: passed tbia test pci: passed pte write cache snoop test pci: failed valid tag invalid pte reload test (mcheck; workaround available) pci: passed pci machine check test got res[8000:807f] for resource 0 of Digital Equipment Corporation DECchip 21142/43 got res[8080:80ff] for resource 1 of Digital Equipment Corporation DEFPA got res[8400:840f] for resource 4 of Contaq Microsystems 82c693 (#2) got res[900:97f] for resource 1 of Matrox Graphics, Inc. MGA 2064W [Millennium] got res[980:983] for resource 6 of Digital Equipment Corporation DECchip 21142/43 got res[984:984] for resource 4 of Contaq Microsystems 82c693 (#3) got res[985:985] for resource 6 of Matrox Graphics, Inc. MGA 2064W [Millennium] got res[986:986] for resource 2 of Digital Equipment Corporation DEFPA got res[987:9873fff] for resource 0 of Matrox Graphics, Inc. MGA 2064W [Millennium] got res[9874000:9874fff] for resource 0 of Contaq Microsystems 82c693 (#4) got res[9875000:987507f] for resource 1 of Digital Equipment Corporation DECchip 21142/43 got res[9876000:987607f] for resource 0 of Digital Equipment Corporation DEFPA got res[9000:90ff] for resource 0 of Q Logic ISP1020 got res[9400:947f] for resource 0 of Digital Equipment Corporation DECchip 21040 [Tulip] got res[990:990] for resource 6 of Q Logic ISP1020 got res[991:9910fff] for resource 1 of Q Logic ISP1020 got res[9911000:991107f] for resource 1 of Digital Equipment Corporation DECchip 21040 [Tulip] PCI: Bus 1, bridge: Digital Equipment Corporation DECchip 21152 IO window: 9000-9fff MEM window: 0990-099f PCI enable device: (Digital Equipment Corporation DECchip 21142/43) cmd reg 0x47 PCI enable device: (Contaq Microsystems 82c693) cmd reg 0x47 PCI enable device: (Contaq Microsystems 82c693 (#2)) cmd reg 0x45 PCI enable device: (Contaq Microsystems 82c693 (#3)) cmd reg 0x47 PCI enable device: (Contaq Microsystems 82c693 (#4)) cmd reg 0x46 PCI enable device: (Matrox Graphics, Inc. MGA 2064W [Millennium]) cmd reg 0x87 PCI enable device: (Digital Equipment Corporation DEFPA) cmd reg 0x47 PCI enable device: (Digital Equipment Corporation DECchip 21152) cmd reg 0x107 PCI enable device: (Q Logic ISP1020) cmd reg 0x47 PCI enable device: (Digital Equipment Corporation DECchip 21040 [Tulip]) cmd reg 0x47 SMC37c669 Super I/O Controller found @ 0x370 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx CY82C693: IDE controller on PCI bus 00 dev 39 CY82C693: chipset revision 0 CY82C693: not 100% native mode: will probe irqs later CY82C693U driver v0.34 99-13-12 Andreas S. Krebs ([EMAIL PROTECTED]) ide0: BM-DMA at 0x8400-0x8407<7>pci_map_single: [fc000191,1000] -> direct 4191 from fc31afa8 , BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0x8408-0x840f<7>pci_map_single: [fc1fa000,1000] -> direct 401fa000 from fc31afa8 , BIOS settings: hdc:pio, hdd:pio hda: TOSHIBA CD-ROM XM-5702B, ATAPI CDROM drive ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: ATAPI 12X CD-ROM drive, 256kB Cache Uniform CD-ROM driver Revision: 3.11 Floppy drive(s): fd0 is 2.88M FDC 0 is a post-1991 82077 Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A rtc: Digital UNIX epoch (1952) detected
Re: [PATCH] Attempt to hard link across filesystems results in
On Mon, 4 Dec 2000, Alan Cox wrote: > > Second attempt, the first one failed due to stupid setup of ISP and the > > usage of mail-abuse.org which blocks anything that has no reverse DNS > > lookup. So some of my messages (about 20%) get lost and I have to resend > > them when I feel it's been too quiet :) > > mail-abuse doesnt do this. One thing it does do however is provide block lists > of addresses where the ISP has said 'this should not be direct mail sources'. Alan, I thank you for sparing a minute to enlighten me. But the _only_ thing I do not understand still (and it appears to be critical) is why it only happens sometimes but not others? i.e. in both times I dialled to btconnect.com and faked From: [EMAIL PROTECTED] (via pine(1) setup). Sometimes it gets through to linux-kernel and sometimes it does not. E.g. this second attempt was sent under exactly the same conditions as the first one. So I was justified in assuming (wrongly as you say) that something external to me was different and the only external thing was dynamic ip address assigned to the ISDN interface of the router. (so I made the assumption that in one case it was lookupable and in another it was not, maybe this assumption is totally broken, i.e. nothing would work if I was _ever_ assigned such address) So, I am still not wiser as to what to do (other than admit to being @btconnect.com :) to make all my messages safely reach linux-kernel. Btconnect.com people also seems to have absolutely no clue so far, unfortunately (probably both me and they are too lazy to (re)read Stevence's TCP/IP Illustrated Volume I and understand how DNS and SMTP are supposed to cooperate). Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Nightly usb oops
On Mon, Dec 04, 2000 at 10:13:09AM -0500, J. Nick Koston wrote: > My machine crashes almost every night with this oops. I've finally > managed to catch it before it was totally gone. This looks like a usb device was unplugged and plugged back in. What devices do you have connected? What host controller driver are you using? What happens to the machine at this time of night (cron jobs, etc.)? What is your .config? What kernel is this (and if 2.4.0-test10, does this also happen on 2.4.0-test12-pre4)? What kind of processor is this? In short, lots more info needed. thanks, greg k-h -- greg@(kroah|wirex).com http://immunix.org/~greg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Attempt to hard link across filesystems results in
> Second attempt, the first one failed due to stupid setup of ISP and the > usage of mail-abuse.org which blocks anything that has no reverse DNS > lookup. So some of my messages (about 20%) get lost and I have to resend > them when I feel it's been too quiet :) mail-abuse doesnt do this. One thing it does do however is provide block lists of addresses where the ISP has said 'this should not be direct mail sources'. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Re[4]: DMA !NOT ONLY! for triton again...
Certain older WDC drives are explicitly blacklisted due to firmware bugs. WDC put out firmware upgrades but given no answer from them on how to be sure a drive was upgraded we play safe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Attempt to hard link across filesystems results inun-unmountable filesystem (fwd)
Second attempt, the first one failed due to stupid setup of ISP and the
usage of mail-abuse.org which blocks anything that has no reverse DNS
lookup. So some of my messages (about 20%) get lost and I have to resend
them when I feel it's been too quiet :)
-- Forwarded message --
Date: Mon, 4 Dec 2000 13:43:20 + (GMT)
From: Tigran Aivazian <[EMAIL PROTECTED]>
To: Christopher Yeoh <[EMAIL PROTECTED]>
Cc: Linus Torvalds <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: [PATCH] Attempt to hard link across filesystems results in
un-unmountable filesystem
On Tue, 21 Nov 2000, Christopher Yeoh wrote:
>
> In 2.4-test11 attempting to hard link a file across filesystems (the
> link does fail correctly) results in one of the filesystems (the one
> the hard link was to be created on) to be in a state such that it
> can't be unmounted.
>
> The attached patch fixes this problem.
Hi Christopher,
It is true that your patch fixes the problem as reported but let us look
one step deeper into the problem. Linux supports multiply mounted
instances of a filesystem and the check in sys_link() comparing the
mountpoints would refuse (with cross-device link error) linking between
them. This is correct. However, one level down, inside vfs_link() we also
check for ->i_dev match and that seems unnecessary, now that (with your
patch) link(2) would work correctly anyway.
Therefore, I propose a slightly modified (tested under
2.4.0-test12-pre4) version of the patch. What do you think? My philosophy
is -- since you made this feature work properly you should make it work
efficiently too and that means removing redundant code.
Regards,
Tigran
--- linux/fs/namei.cMon Dec 4 08:43:35 2000
+++ work/fs/namei.c Mon Dec 4 12:34:24 2000
@@ -1551,10 +1551,6 @@
if (error)
goto exit_lock;
- error = -EXDEV;
- if (dir->i_dev != inode->i_dev)
- goto exit_lock;
-
/*
* A link to an append-only or immutable file cannot be created.
*/
@@ -1611,7 +1607,7 @@
goto out;
error = -EXDEV;
if (old_nd.mnt != nd.mnt)
- goto out;
+ goto out2;
new_dentry = lookup_create(, 0);
error = PTR_ERR(new_dentry);
if (!IS_ERR(new_dentry)) {
@@ -1619,6 +1615,7 @@
dput(new_dentry);
}
up(>d_inode->i_sem);
+out2:
path_release();
out:
path_release(_nd);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i810_audio 2.4.0-test11
Alan Cox wrote: > What format is it that causes the problems, the only badly supported key format > right know I know of is 16bit bigendian. That needs some small esd patches. S8 is a not very well supported format. And btw there are many applications that cannot live with esd for latency reasons. Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: using TOS as a key in route cache
Hello Thanks for your reply. But this can create problems in some of the cases. For example, "scp" over TCP starts with TOS 0, then goes to 8 (bulk data). What happens is that when RTOs are cached, they are updated for TOS 8 and not for TOS 0, therefore a new connection does not pick up the cached RTO. Does this make sense ? Thanks, -- Rajeev (Again, please cc replies to [EMAIL PROTECTED]) On Mon, 4 Dec 2000, Helge Hafting wrote: > Rajeev Bector wrote: > > > > Guys > > I am looking for a reason as to why we want > > to have different route cache entries for > > different IP ToS types. Does anyone have > > any insight into this ? > > Because you may want to route time-critical stuff like > video through a dedicated fast network and slow stuff like email > through another. Such a setup prevents an email burst from > disrupting video. > > There are many similiar uses. > > Helge Hafting > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] inode dirty blocks Re: test12-pre4
On Mon, Dec 04, 2000 at 01:01:36AM -0500, Alexander Viro wrote: > > It doesn't solve the problem. If you unlink a file with dirty metadata > you have a nice chance to hit the BUG() in inode.c:83. I hope that patch > below closes all remaining holes. See analysis in previous posting > (basically, bforget() is not enough when we free the block; bh should > be removed from the inode's list regardless of the ->b_count). Agreed. However, is there any reason to have this as a separate function? bforget() should _always_ remove the buffer from any inode queue. You can make that operation conditional on (bh->b_inode != NULL) if you want to avoid taking the lru lock unnecessarily. --Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i810_audio 2.4.0-test11
> Anything in between is IMO silly. Killing the format > conversion drops the advantage of running many existing > applications but don't bring you much closer to the goal > of simplicity. Those applications already have to deal with the fact some devices only support 48KHz 16bit stereo audio. I run a full desktop environment on such hardware without problems. What format is it that causes the problems, the only badly supported key format right know I know of is 16bit bigendian. That needs some small esd patches. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re[4]: DMA !NOT ONLY! for triton again...
Thanks, Andre! Briefly, the problem is that I can't turn on DMA for a WDC AC21600H CCC F6 drive, all the details are on this mailing list, but I'll put them all together in a single message and email it to you personally, ok? There is still a SMALL chance, that the problem is solvable locally by myself, or maybe it simply can't be solved in principle for this hardware. I very much doubt that my BIOS is quite capable of handling DMA on IDE, but that shouldn't prevent the kernel from using it, right? BTW, Mike, you might want to have a look at http://www.linux.com/tuneup/database.phtml/Hardware/000838.html - I just found it. Somebody there suggests, that you actually have to turn OFF PIO support in the kernel. Will million-check this later... But I wouldn't like to corrupt the disk by 'disabling all BIOS settings' as the author there suggests... At least not LBA... Thanks again to all Guennadi -Original Message- > > Guennadi, > > I have watched this and even if UDMA is not supported cleanly by the > drive, the classic ATA-2 Multi-wrod DMA should be. There was a time in > the past where WDC had some problems, but they have fixed most if not all > with "modern" drives. I will be at WDC in two weeks, and I can raise the > issues with them. Please spell them out completely. > > Regards, > > On Mon, 4 Dec 2000, Guennadi Liakhovetski wrote: > > > Well, yes, I thought they could not have known:-)) I'm absolutely stuck. If disk >is fine, chipset is fine and supported by the kernel, then BIOS doesn't (or >shouldn't) make a difference... Then WHAT ON THE EARTH??? Mike, have you been able to >recall what BIOS option turned DMA on? Shall I write to Andre Hedrick directly? Or is >there a mailing-list smth. like linux-ide? > > > > > Now, the question is, can we trust a hard drive manufacturer > > > support tech to know what they're talking about, with evidence to > > > the contrary? :) > > > > Thanks > > Guennadi > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > Please read the FAQ at http://www.tux.org/lkml/ > > > > Andre Hedrick > CTO Timpanogas Research Group > EVP Linux Development, TRG > Linux ATA Development > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Path: for oom_kill.c
On Mon, Dec 04, 2000 at 02:57:34PM -0200, Rik van Riel wrote: > On Sat, 2 Dec 2000, hugang wrote: > > > Hello all: > > > > old> points = p->mm->total_vm; > > > > change to ---> points = p->pid; > > Ummm, what exactly do you want to achieve with this? I suspect that hugang whishes to kill the newest process. However, this will not work after PID wrap. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Re[2]: DMA !NOT ONLY! for triton again...
Guennadi, I have watched this and even if UDMA is not supported cleanly by the drive, the classic ATA-2 Multi-wrod DMA should be. There was a time in the past where WDC had some problems, but they have fixed most if not all with "modern" drives. I will be at WDC in two weeks, and I can raise the issues with them. Please spell them out completely. Regards, On Mon, 4 Dec 2000, Guennadi Liakhovetski wrote: > Well, yes, I thought they could not have known:-)) I'm absolutely stuck. If disk is >fine, chipset is fine and supported by the kernel, then BIOS doesn't (or shouldn't) >make a difference... Then WHAT ON THE EARTH??? Mike, have you been able to recall >what BIOS option turned DMA on? Shall I write to Andre Hedrick directly? Or is there >a mailing-list smth. like linux-ide? > > > Now, the question is, can we trust a hard drive manufacturer > > support tech to know what they're talking about, with evidence to > > the contrary? :) > > Thanks > Guennadi > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > Andre Hedrick CTO Timpanogas Research Group EVP Linux Development, TRG Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re[2]: DMA !NOT ONLY! for triton again...
Well, yes, I thought they could not have known:-)) I'm absolutely stuck. If disk is fine, chipset is fine and supported by the kernel, then BIOS doesn't (or shouldn't) make a difference... Then WHAT ON THE EARTH??? Mike, have you been able to recall what BIOS option turned DMA on? Shall I write to Andre Hedrick directly? Or is there a mailing-list smth. like linux-ide? > Now, the question is, can we trust a hard drive manufacturer > support tech to know what they're talking about, with evidence to > the contrary? :) Thanks Guennadi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0.12.4: dummy.o problem (again)
A better (right, IMVHO) patch is:
--- linux-2.4.0-test/include/linux/module.h~Mon Dec 4 09:06:47 2000
+++ linux-2.4.0-test/include/linux/module.h Mon Dec 4 13:55:18 2000
@@ -345,7 +345,7 @@
#endif /* MODULE */
#ifdef CONFIG_MODULES
-#define SET_MODULE_OWNER(some_struct) do { some_struct->owner = THIS_MODULE; } while
(0)
+#define SET_MODULE_OWNER(some_struct) do { (some_struct)->owner = THIS_MODULE; }
+while (0)
#else
#define SET_MODULE_OWNER(some_struct) do { } while (0)
#endif
--
Dr. Horst H. von Brand mailto:[EMAIL PROTECTED]
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, ChileFax: +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Path: for oom_kill.c
On Sat, 2 Dec 2000, hugang wrote: > Hello all: > > old> points = p->mm->total_vm; > > change to ---> points = p->pid; Ummm, what exactly do you want to achieve with this? > before change it ,kernel will kill some pid, to change it kernel > will kill hello(bash). Before the change, the kernel will try to kill a BIG process (the obvious suspect for a memory leak). After the change, the kernel will kill an almost random process ... regards, Rik -- Hollywood goes for world dumbination, Trailer at 11. http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0.12.4: drivers/net/dummy.c fails compile
On Mon, 4 Dec 2000, Horst von Brand wrote: > SPARC64, Red Hat 6.2 + local updates A better patch has already been posted, and is present in the 2.4.0-test11-ac series. module.h needs to be modified to protect the argument of SET_MODULE_OWNER. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11
Hello Again
Some more details, now that I scraped a few minutes on the weekend to
look into this.
Same hardware configuration as my earlier post; with a newer bios
version on the motherboard; with no improvement.
Some long winded test results, and my conclusions:
[abridged] output from diff for one flawed copy:
===
linux/fs/cramfs/inflate/inffixed.h
-{{{84,7}},99}, {{{0,8}},127}, {{{0,8}},63}, {{{0,9}},223},
+{{{84,7}},99}, {{{0,8}},127}{0,8}},63}, {{{0,9}},223},
linux/fs/jffs/intrep.c
- jffs_fmfree_partly(fmc, fm, total_data_size);
- jffs_fm_write_unlock(fmc);
+ jffs_fmfree_partly(fmc, fm,
total_data_sizport jffs_fm_write_unlock(fmc);
linux/kernel/resource.c
-int allocate_resource(struct resource *root, struct resource *new,
+int allocate_rrce(struct resource *root, struct resource *new,
===
Closer inspection of the three "corrupt" files, using the command
od -tc | less
revealed that in all cases, the corruption was the four bytes
immediately preceding an exact multiple of 4096 - the block size for the
(ext2) fs...
I may well go back and read the "corruption" thread which gave me the
idea for the comparison when I wake up :(
for inffixed.h, the correct dump reads
0017740 { { { 8 4 , 7 } } , 9 9 } , {
0017760 { { 0 , 8 } } , 1 2 7 } , { {
002 { 0 , 8 } } , 6 3 } , { { { 0
0020020 , 9 } } , 2 2 3 } , \n {
and the flawed dump reads
0017740 { { { 8 4 , 7 } } , 9 9 } , {
0017760 { { 0 , 8 } } , 1 2 7 } \0 \0 \0 \0
002 { 0 , 8 } } , 6 3 } , { { { 0
0020020 , 9 } } , 2 2 3 } , \n {
0x002 -> 131072 -> 32 x 4k
likewise for intrep.c
0177740 r t l y ( f m c , f m , t o
0177760 t a l _ d a t a _ s i z e ) ; \n
020 \t \t \t j f f s _ f m _ w r i t e
0200020 _ u n l o c k ( f m c ) ; \n \t \t
and the flawed dump reads
0177740 r t l y ( f m c , f m , t o
0177760 t a l _ d a t a _ s i z p o r t
020 \t \t \t j f f s _ f m _ w r i t e
0200020 _ u n l o c k ( f m c ) ; \n \t \t
0x020 -> 2097152 -> 512 x 4k
I have a couple more examples; the corruption is still present after a
reboot; but I have yet to see what fsck makes of it...
[Addendum: corruption is still present after fsck]
So, in summary; when using the HPT366 controller with my claimed ATA66
drive; using an SMP kernel with two Celeron 466's (at 466), under load I
find intermittant corruption of the ext2 filesystem.
always four bytes; and apparently commonly (maybe always?) the four
before an exact multiple of 4096 bytes - the filesystem block size.
The values that are written instead of the correct data do not appear to
be random; but rather data from the (memory) cache; I've noticed one or
two previously that look "familiar"; but that may just be my tired eyes.
That's all I can think (ramble?) of at this time; Awaiting bright ideas;
or more free time to fiddle more. Thanks in Advance (for all the bright
ideas :) )
Gerard Sharp
Two Penguins at 1024x768
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i810_audio 2.4.0-test11
On Mon, 4 Dec 2000, Thomas Sailer wrote: > And before killing format conversion you should kill > the mmap stunt, because the format conversion complexity > (~25 LOC) is by far dwarfed by the mmap emulation stuff. mmap -emulation- ?? Ug. Is Quake really worth that much? :) > The underlying question is: > > - do we want an usb audio driver that supports the OSS > interface and with which most existing applications work of course > Anything in between is IMO silly. Killing the format > conversion drops the advantage of running many existing > applications but don't bring you much closer to the goal > of simplicity. OSS has always implied that the software performs conversions when the hardware cannot support certain formats. And the kernel direction has always been to -remove- any software conversion code. We removed SoftOSS, for example. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0.12.4: drivers/net/dummy.c fails compile
SPARC64, Red Hat 6.2 + local updates dummy.c: In function `dummy_init_module': dummy.c:103: invalid type argument of `->' A patch follows: --- linux-2.4.0-test/drivers/net/dummy.c~ Mon Dec 4 09:03:05 2000 +++ linux-2.4.0-test/drivers/net/dummy.cMon Dec 4 13:27:23 2000 @@ -100,7 +100,7 @@ int err; dev_dummy.init = dummy_init; - SET_MODULE_OWNER(_dummy); + SET_MODULE_OWNER((_dummy)); /* Find a name for this unit */ err=dev_alloc_name(_dummy,"dummy%d"); -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.40.t11: Unresolved symbols while insmodding ip_tables.
Hi, I got problems using ip_tables. Insmodding ip_tables gives me: /lib/modules/2.4.0-test11/kernel/net/ipv4/netfilter/ip_tables.o: unresolved symbol nf_unregister_sockopt /lib/modules/2.4.0-test11/kernel/net/ipv4/netfilter/ip_tables.o: unresolved symbol nf_register_sockopt /lib/modules/2.4.0-test11/kernel/net/ipv4/netfilter/ip_tables.o: insmod /lib/modules/2.4.0-test11/kernel/net/ipv4/netfilter/ip_tables.o fail I tried it with modutils 2.3.18 and the newest version 2.3.21, but both fail. The System.map does have these two symbols. netsyms.o does also have these symbols. Why haven't _I_ these symbols ;o) Any help very appreciated! Thank you very much in advance. keep hacking the right site of life ! :-) Meino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
