Re: 2.4.4 kernel freeze for unknown reason
On Fri, 11 May 2001, Alan Cox wrote: > > I have been monitoring the memory usage constantly with the gnome > > memory usage meter and noticed that as swap grows it is never freed > > back up. I can kill off most of the large applications, such as I've seen this mentioned a few times now and am curious enough to ask. > The swap handling in 2.4 is somewhat hosed at the moment. > > > If I turn swap off all together or turn it off and back on > > periodically to clear the swap before it gets full, I do not seem to > > experience the lockups. Why do I not see this behavior with a heavy swap throughput test load? It seems decidedly odd to me that swapspace should remain allocated on other folks lightly loaded boxen given that my heavily loaded box does release swapspace quite regularly. What am I missing? -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
testing new vger
Ignore this post please, thanks. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Chat rooms for linux kernel developers
Good day, Jaswinder, On Fri, 11 May 2001, Jaswinder Singh wrote: > Is there is any chat (IRC) for linux kernel developers . See irc.linpeople.org, channel #kernelnewbies . Cheers, - Bill --- "If you think technology can solve your security problems, then you don't understand the problems and you don't understand the technology." -- Bruce Schneier, Secrets and Lies -- William Stearns ([EMAIL PROTECTED]). Mason, Buildkernel, named2hosts, and ipfwadm2ipchains are at:http://www.pobox.com/~wstearns LinuxMonth; articles for Linux Enthusiasts! http://www.linuxmonth.com -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM 1.0 release decision
Andrea Arcangeli writes: > you _must_ know very well what the mainteinance of that code means ;). Which is why I added the facility by which such ioctl conversions can be registered at runtime by the subsystem/driver itself. > BTW, it would be nice if somebody would take care of unifying the > large sharable parts of the emulation code between > x86-64/sparc64/ia64/mips64, this was mentioned by Andi several times but > nothing is been done in that direction yet, they for large part do the > same things and somehow we duplicate efforts across all those ports (if > we exclude the regs maniuplation in the ELF_PLAT_DATA and friends that > can be localized easily). If we do that kind of sharing all the other > ports would probably get the 32bit emulation for the lvm ioctl for free > from the sparc64 effort for example. I'm already planning on doing this, but it is a 2.5.x project. Dave Mosberger agrees with this as has anyone else I've mentioned the idea to, so consider it basically done in 2.5.x sometime. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ENOIOCTLCMD?
Can somebody explain the use of ENOIOCTLCMD? There are order of 170 uses in the kernel, but I don't see any guidelines for that use (nor what prevents it from being seen by user programs). Thanks. errno.h: >/* Should never be seen by user programs */ >#define ERESTARTSYS512 >#define ERESTARTNOINTR 513 >#define ERESTARTNOHAND 514 /* restart if no handler.. */ >#define ENOIOCTLCMD515 /* No ioctl command */ -- /Jonathan Lundell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in 2.4.4-ac6, ksymoops output included
On Fri, 11 May 2001 17:52:24 -0400 (EDT), "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: >ksymoops 2.4.1 on i686 2.4.4-ac6. Options used >Warning (read_object): no symbols in >/lib/modules/2.4.4-ac6/build/drivers/pnp/pnp.o ksymoops should not be reading objects from /build/. It looks like you are running an old modutils, you need at least modutils 2.4.2 for 2.4 kernels. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] adding PCI bus information to SCSI layer
At 11:20 PM -0300 2001-05-11, Ralf Baechle wrote: >On Fri, May 11, 2001 at 03:49:05PM -0700, Jonathan Lundell wrote: > >It's 998 plus a CR/LF sequence which is 1000 bytes, not exactly an odd >number. And it's the official successor of RFC 822 which was an official >STD. What I meant by "strange" was that it's neither so large a number that keeping track is not a concern, nor so small that it fits on a screen (or is reasonable to scroll). Yes, it does appear to be a standard; I was confused because it hadn't propagated everywhere. -- /Jonathan Lundell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Not a typewriter
On Fri, 11 May 2001 11:07:45 -0500, [EMAIL PROTECTED] wrote: > > >On 05/10/2001 at 06:20:34 PM Hacksaw <[EMAIL PROTECTED]> wrote: > >My point is that someone who sees the "typewriter" message and doesn't >understand it will have to dig a bit to find out what it means. Finding it >almost certainly will involve uncovering some of the history and folklore of >Unix. In the "Intro to Unix" classes I've taught over the years, I've always >made a point of explaining the background of things like this -- such as the >relation of grep to the g/re/p expression of ed, ex and vi; where biff got its >name; what the letters stand for in awk; why creat doesn't end in an "e;" and so >forth. I tell the class that Unix has quirky, eccentric, whimsical elements >because many of the things in it were written by quirky, eccentric, or whimsical >people. The comment at the bottom of some versions of the tunefs man page (such >as the HP-UX version) is an example I like to use: "You can tune a file system, >but you can't tune a fish." I tell them they'll understand the Unix way of >thinking faster if they approach it with an inquisitive, playful spirit rather >than as a stuffy business system. It's supposed to be correct; it's supposed to >be efficient; but it's also supposed to be fun, and sometimes the fun is worth >sacrificing a little of the other qualities in trivial areas. > >I guess what I'm trying to say is that "Life With Unix" should be required >reading for anyone who goes near a Unix (or Linux) system. David N. Smith, an IBM researcher, wrote that we should preserve the past for the criticism of the future. john alvord - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.4.4ac7 oops, locks in init on boot
On Fri, 11 May 2001, Alan Cox wrote: > > If anyone has any further suggestions/patches to run 2.4.x with K7 > > chosen optimizations, I'm open to testing. > > 'Buy an AMD chipset box..' > > Seriously at this point I am out of ideas. The prefetch to far effect > explained the old athlon locks (step 1) people reported on all chipsets. It > didnt really seem to explain the problem with a few via chipset boards but I > was hopeful. So are you saying that given the current information available you have you do not know how to fix the via -> Athlon stuff or am I reading too much into this? I am looking at buying an Athlon board soon and I am trying to figure out if I should avoid via at all costs or not. TIA, -- ..Tom DISSERVICE: It Takes Months to Find a Customer, but [EMAIL PROTECTED] Only Seconds to Lose One... The good News is that We Should Run Out of Them In No Time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: test -please disregard
On Fri, May 11, 2001 at 08:39:28PM +0300, Matti Aarnio wrote:
...
>Unfortunately I don't have a clue as to why it has been failing,
>but the kernel is a bit old...
>
> Linux vger.redhat.com 2.2.12-20 #1 Mon Sep 27 10:40:35 EDT 1999 i686 unknown
On a not very loaded dual classic P133:
[root /root]# uname -a
Linux xxx.xxx.xxx 2.2.12-20smp #1 SMP Mon Sep 27 10:20:02 EDT 1999 i586 unknown
[root /root]# uptime
4:34am up 441 days, 9:14, 1 user, load average: 0.21, 0.13, 0.10
Just wanted to chirp in with a little good news :)
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] adding PCI bus information to SCSI layer
On Fri, May 11, 2001 at 03:49:05PM -0700, Jonathan Lundell wrote: > >> >If you want to support wrapping with plain text, investigate > >> >format=flowed. > >> > >> Yes, I did that. > >> > > > I'm curious, though: I haven't found the mail standards that forbid > >> receivers to wrap long lines. Certainly many mail clients do it. > >> What's the relevant RFC? > > > >RFC 2822, 2.1.1. > > Thanks. It's not quite a standard yet, but it's true, it does limit > lines to 998 characters. Sort of a strange limit, but there you > are It's 998 plus a CR/LF sequence which is 1000 bytes, not exactly an odd number. And it's the official successor of RFC 822 which was an official STD. Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM 1.0 release decision
On Fri, May 11, 2001 at 01:12:55PM -0700, David S. Miller wrote: > They can be converted, [..] of course, and part of that code will be still necessary also with the >=beta4 lvm interface to still convert the pointers of the userspace data structures but my point was we probably want to avoid that complexity where it's not necessary (feasible was too strong adj sorry). Related side note: for the x86-64 kernel we won't support the emulation of the lvm ioctl from the 32bit executables to avoid the pointer conversion an mainteinance pain enterely, at least in the early stage the x86-64 lvmtools will have to be compiled elf64. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM 1.0 release decision
Andrea Arcangeli writes: > Related side note: for the x86-64 kernel we won't support the emulation > of the lvm ioctl from the 32bit executables to avoid the pointer > conversion an mainteinance pain enterely, at least in the early stage > the x86-64 lvmtools will have to be compiled elf64. I think that's a bad decision, but it is your's. To me, either you support fully the 32-bit execution environment or you do not. After all the work that myself and others have done for other platforms, there really is no need to cut corners in this area. My userland on sparc64 is %100 32-bit and everything works quite beautifully. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: User-mode Linux ported to ppc
[EMAIL PROTECTED] said: > User-mode Linux is now booting on PPC Linux - it can boot with a > Debian root floppy image with init=/bin/sh and poke around. It mostly > works, although there are still a few problems. First off, I'd like to thank Chris for volunteering to undertake the first port of UML and seeing it through to the point where it's basically working. It's a nice demonstration, if any were needed, that UML isn't i386-only. Based on what I've learned from this port, I'm writing up what amounts to a UML porting guide. It will be found at http://user-mode-linux.sourceforge.net/ arch-port.html when I have something ready. It will be incomplete at first - I'll be filling it in as I go through the existing code and as I finish integrating Chris's code into my pool. So, if anyone wants to port UML to another arch, have a look at that page (and continue looking as I fill it in :-). You'll see that it's not a huge amount of work. UML is fairly portable. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ncr53c8xx - DAT detection problem - 2.2.14-5
Geert, I have "CONFIG_CHR_DEV_ST=y" in my "/usr/src/linux/.config" file.
Any ideas?
- Original Message -
From: "Geert Uytterhoeven" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "kernel" <[EMAIL PROTECTED]>
Sent: Friday, May 11, 2001 12:45 AM
Subject: Re: ncr53c8xx - DAT detection problem - 2.2.14-5
> On Thu, 10 May 2001, Tim Moore wrote:
> > Any clues as to why /dev/st0 is never initialized for DAT tape? Please
cc [EMAIL PROTECTED] if more
> > info is needed.
>
> Make sure CONFIG_CHR_DEV_ST=[ym]
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
[EMAIL PROTECTED]
>
> In personal conversations with technical people, I call myself a hacker.
But
> when I'm talking to journalists I just say "programmer" or something like
that.
> -- Linus Torvalds
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: USB broken in 2.4.4? Serial Ricochet works, USB performancesucks.
On Thu, 10 May 2001, Drew Bertola wrote: > > The Richochet USB stuff uses generic serial I/O. No special driver. And it > > works fine under Win/ME. Have you run a regular PPP connection over the > > ACM driver with an MTU of 1500? > > Joey Hess had a problem similar to what you described, though he noticed > it while using the pcmcia ricochet modem. He passed along this patch: I tried the patch a couple of days ago and it did not do anything for me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM 1.0 release decision
On Fri, May 11, 2001 at 06:29:27PM -0700, David S. Miller wrote: > I think that's a bad decision, but it is your's. Let me put it this way: after I get the first real life request from an user with an useful case where a 32bit app needs to run the lvm ioctl it will be truly easy to change my mind about that, I just don't expect to get that request anytime soon because the only thing that runs the lvm ioctl are the lvmtools, and I assume Andi thought the same when he originally proposed not to support the lvm ioctl from the 32bit userland. If you just have in mind something of useful that needs that please let us know and we will definitely listen to you. Of course not implementing the 32bit lvm ioctl emulation now, in any case won't forbid us to implement it in the next 5 minutes, we can do that anytime if/when we find the first useful case that needs that, it's just a matter of cut and pasting from the ioctl32.c of sparc64 to the x86-64 tree and then to spend one day of hacking and testing through those pointer conversions, being aware that this work will break in the next two weeks when a new lvm ioctl is added in the next lvm release, or something like that, you _must_ know very well what the mainteinance of that code means ;). BTW, it would be nice if somebody would take care of unifying the large sharable parts of the emulation code between x86-64/sparc64/ia64/mips64, this was mentioned by Andi several times but nothing is been done in that direction yet, they for large part do the same things and somehow we duplicate efforts across all those ports (if we exclude the regs maniuplation in the ELF_PLAT_DATA and friends that can be localized easily). If we do that kind of sharing all the other ports would probably get the 32bit emulation for the lvm ioctl for free from the sparc64 effort for example. > To me, either you support fully the 32-bit execution > environment or you do not. After all the work that > myself and others have done for other platforms, there > really is no need to cut corners in this area. > > My userland on sparc64 is %100 32-bit and everything works > quite beautifully. The sparc platform is a completly different matter, you cannot compare sparc64 to x86-64, on sparc64 the 64bit userspace is a very recent thing (just to make an example my sparc64 still runs only with the 32bit userspace and I use the 64bit compiler only for the kernel, I don't know if you have a total 64bit userspace either). For sparc64 a 64bit-only lvmtools would been a very nasty dependency and so for sparc64 it is almost mandatory to support completly all the ioctls from the 32bit userland. On x86-64 the only reason for having a program 32bit is because it's either binary only, or if you need to reduce the memory footprint and you don't need more than 4G of address space [btw all the binaries running in compatibility mode on the x86-64 kernel will get 4G of address space, 1G more than with a ia32 kernel]. lvmtools are GPL'd and the memory footprint of the lvmtools is absolutely worthless to consider. So there's no point to compile the lvmtools 32bit, period. And I think your "everything works quite beautifully" on sparc64 isn't really the case if you upgrade to a recent lvm revision unless you fixup all the 32bit ioctl emulation first, the reason we want "everything works beautifully and always" is the main reason we try to avoid the lvm ioctl 32bit emulation ;), at least with the current lvm user<->kernel design. Furthmore if somebody post a patch that implements the ioclt wrappers even if there isn't an useful case that needs them, I will be glad to checkin that code after adding a fat warning in the source that says it can break anytime. the lvm ioctl can be run only by the administrator so it won't be a security breach if they breaks when the drivers/md/lvm* code gets updated and what I will do in my box will be to compile the lvmtools with a plain `make` anyways, so my lvmtools will run 64bit anyways and I will never test that wrappers myself (and after some time they remains broken I will end putting an #if 0 /* FIXME */ around the wrappers to avoid somebody getting bitten by that code). So in short to me it sounds a good decision and also a no brainer one that we can change anytime if we need to. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Chat rooms for linux kernel developers
Dear linux kernel mailing list , Is there is any chat (IRC) for linux kernel developers . Thank you , Best Regards, Jaswinder. -- These are my opinions not 3Di. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Configuring shared memory
Hi, Can somebody please tell me how to configure the amount of shared memory that a 2.2.x kernel allocates? Kindly copy to my e-mail address ([EMAIL PROTECTED]). Thanks, Sriram _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PCI ID Fixups for Intel 82801BA & BAM
Below is a quick patch to fix the PCI ID's for the 82801BA and add ID's for
the mobile version, the 82801BAM. The DID's are from Intel developer docs, I
don't remember the URL. It's easy to find. Fixes the unknown IDE controller
problem for Dell Inspiron 8000 and one of the newer Sony Vaio's.
Tim
diff -u -r linux/drivers/ide/ide-pci.c linux_new/drivers/ide/ide-pci.c
--- linux/drivers/ide/ide-pci.c Fri May 11 22:31:35 2001
+++ linux_new/drivers/ide/ide-pci.c Fri May 11 21:18:18 2001
@@ -34,7 +34,8 @@
#define DEVID_PIIX4U ((ide_pci_devid_t){PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_82801AA_1})
#define DEVID_PIIX4U2 ((ide_pci_devid_t){PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_82372FB_1})
#define DEVID_PIIX4NX ((ide_pci_devid_t){PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_82451NX})
-#define DEVID_PIIX4U3 ((ide_pci_devid_t){PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_82820FW_5})
+#define DEVID_PIIX4U3 ((ide_pci_devid_t){PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_82801BA_9})
+#define DEVID_PIIX4U4 ((ide_pci_devid_t){PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_82801BA_8})
#define DEVID_VIA_IDE ((ide_pci_devid_t){PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_82C561})
#define DEVID_VP_IDE ((ide_pci_devid_t){PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_82C586_1})
#define DEVID_PDC20246 ((ide_pci_devid_t){PCI_VENDOR_ID_PROMISE,
PCI_DEVICE_ID_PROMISE_20246})
@@ -343,6 +344,7 @@
{DEVID_PIIX4U2, "PIIX4",PCI_PIIX, ATA66_PIIX, INIT_PIIX,
NULL,
{{0x41,0x80,0x80}, {0x43,0x80,0x80}}, ON_BOARD, 0 },
{DEVID_PIIX4NX, "PIIX4",PCI_PIIX, NULL, INIT_PIIX,
NULL,
{{0x41,0x80,0x80}, {0x43,0x80,0x80}}, ON_BOARD, 0 },
{DEVID_PIIX4U3, "PIIX4",PCI_PIIX, ATA66_PIIX, INIT_PIIX,
NULL,
{{0x41,0x80,0x80}, {0x43,0x80,0x80}}, ON_BOARD, 0 },
+ {DEVID_PIIX4U4, "PIIX4",PCI_PIIX, ATA66_PIIX, INIT_PIIX,
+ NULL,
{{0x41,0x80,0x80}, {0x43,0x80,0x80}}, ON_BOARD, 0 },
{DEVID_VIA_IDE, "VIA_IDE", NULL, NULL, NULL,
NULL, {{0x00,0x00,0x00},
{0x00,0x00,0x00}}, ON_BOARD, 0 },
{DEVID_VP_IDE, "VP_IDE", PCI_VIA82CXXX,
ATA66_VIA82CXXX,INIT_VIA82CXXX,
DMA_VIA82CXXX, {{0x40,0x02,0x02}, {0x40,0x01,0x01}}, ON_BOARD, 0 },
{DEVID_PDC20246,"PDC20246", PCI_PDC202XX, NULL, INIT_PDC202XX,
NULL,
{{0x50,0x02,0x02}, {0x50,0x04,0x04}}, OFF_BOARD, 16 },
diff -u -r linux/drivers/ide/piix.c linux_new/drivers/ide/piix.c
--- linux/drivers/ide/piix.cTue Mar 6 22:44:34 2001
+++ linux_new/drivers/ide/piix.cFri May 11 21:42:04 2001
@@ -108,7 +108,8 @@
c1 = inb_p((unsigned short)bibma + 0x0a);
switch(bmide_dev->device) {
- case PCI_DEVICE_ID_INTEL_82820FW_5:
+ case PCI_DEVICE_ID_INTEL_82801BA_8:
+ case PCI_DEVICE_ID_INTEL_82801BA_9:
p += sprintf(p, "\nIntel PIIX4
Ultra 100
Chipset.\n");
break;
case PCI_DEVICE_ID_INTEL_82372FB_1:
@@ -358,7 +359,8 @@
bytespeed;
byte udma_66= eighty_ninty_three(drive);
- int ultra100= ((dev->device == PCI_DEVICE_ID_INTEL_82820FW_5)) ? 1
: 0;
+ int ultra100= ((dev->device == PCI_DEVICE_ID_INTEL_82801BA_8) ||
+ (dev->device == PCI_DEVICE_ID_INTEL_82801BA_9)) ? 1
+: 0;
int ultra66 = ((ultra100) ||
(dev->device == PCI_DEVICE_ID_INTEL_82801AA_1) ||
(dev->device == PCI_DEVICE_ID_INTEL_82372FB_1)) ? 1
: 0;
diff -u -r linux/drivers/pci/pci.ids linux_new/drivers/pci/pci.ids
--- linux/drivers/pci/pci.ids Sun Mar 25 21:14:20 2001
+++ linux_new/drivers/pci/pci.ids Fri May 11 22:10:32 2001
@@ -4592,13 +4592,18 @@
11d4 0048 SoundMAX Integrated Digital Audio
2426 82801AB AC'97 Modem
2428 82801AB PCI Bridge
- 2440 82820 820 (Camino 2) Chipset ISA Bridge (ICH2)
- 2442 82820 820 (Camino 2) Chipset USB (Hub A)
- 2443 82820 820 (Camino 2) Chipset SMBus
- 2444 82820 820 (Camino 2) Chipset USB (Hub B)
- 2449 82820 820 (Camino 2) Chipset Ethernet
- 244b 82820 820 (Camino 2) Chipset IDE U100
- 244e 82820 820 (Camino 2) Chipset PCI
+ 2440 82801BA ISA Bridge (ICH2)
+ 2442 82801BA(M) USB (Hub A)
+ 2443 82801BA(M) SMBus
+ 2444 82801BA(M) USB (Hub B)
+ 2445 82801BA(M) AC'97 Audio
+ 2446 82801BA(M) AC'97 Modem
+ 2448 82801BA PCI
+ 2449 82801BA(M) Ethernet
+ 244a 82801BAM IDE U100
+ 244b 82801BA IDE U100
+ 244c 82801BAM ISA Bridge (ICH2)
+ 244e 82801BAM PCI
2500 82820
Re: 2.4.4-ac8 doesn't work with Lite-On 82c168 PNIC rev 32
Here's another patch to try, for PNIC. Feedback welcome. -- Jeff Garzik | Game called on account of naked chick Building 1024| MandrakeSoft | diff -ur 2.4/drivers/net/tulip/media.c build-2.4/drivers/net/tulip/media.c --- 2.4/drivers/net/tulip/media.c Fri May 11 22:12:51 2001 +++ build-2.4/drivers/net/tulip/media.c Fri May 11 22:10:03 2001 @@ -409,8 +409,6 @@ struct tulip_private *tp = dev->priv; unsigned int bmsr, lpa, negotiated, new_csr6; - if (tp->full_duplex_lock) - return 0; bmsr = tulip_mdio_read(dev, tp->phys[0], MII_BMSR); lpa = tulip_mdio_read(dev, tp->phys[0], MII_LPA); if (tulip_debug > 1) @@ -428,7 +426,7 @@ } } negotiated = lpa & tp->advertising[0]; - tp->full_duplex = (mii_nway_result(negotiated) & LPA_DUPLEX) ? 1 : 0; + tp->full_duplex = tp->full_duplex_lock | (mii_nway_result(negotiated) & +LPA_DUPLEX) ? 1 : 0; new_csr6 = tp->csr6;
Re: 2.4.4-ac8 doesn't work with Lite-On 82c168 PNIC rev 32
Does this patch, against ac8, help with the PNIC problem?
--
Jeff Garzik | Game called on account of naked chick
Building 1024|
MandrakeSoft |
Index: drivers/net/tulip/media.c
===
RCS file: /cvsroot/gkernel/linux_2_4/drivers/net/tulip/media.c,v
retrieving revision 1.1.1.30
diff -u -r1.1.1.30 media.c
--- drivers/net/tulip/media.c 2001/05/11 23:58:47 1.1.1.30
+++ drivers/net/tulip/media.c 2001/05/12 00:47:16
@@ -255,7 +255,7 @@
case 1: case 3: {
int phy_num = p[0];
int init_length = p[1];
- u16 *misc_info;
+ u16 *misc_info, tmp_info;
dev->if_port = 11;
new_csr6 = 0x020E;
@@ -282,8 +282,10 @@
for (i = 0; i < init_length; i++)
outl(init_sequence[i], ioaddr + CSR12);
}
- tp->advertising[phy_num] = get_u16(_info[1]) | 1;
- if (startup < 2) {
+ tmp_info = get_u16(_info[1]);
+ if (tmp_info)
+ tp->advertising[phy_num] = tmp_info | 1;
+ if (tmp_info && startup < 2) {
if (tp->mii_advertise == 0)
tp->mii_advertise = tp->advertising[phy_num];
if (tulip_debug > 1)
Index: drivers/net/tulip/tulip_core.c
===
RCS file: /cvsroot/gkernel/linux_2_4/drivers/net/tulip/tulip_core.c,v
retrieving revision 1.1.1.43
diff -u -r1.1.1.43 tulip_core.c
--- drivers/net/tulip/tulip_core.c 2001/05/11 23:58:48 1.1.1.43
+++ drivers/net/tulip/tulip_core.c 2001/05/12 00:47:17
@@ -20,10 +20,11 @@
#include
#include
#include
+#include
#include
static char version[] __devinitdata =
- "Linux Tulip driver version 0.9.14f (May 10, 2001)\n";
+ "Linux Tulip driver version 0.9.15cvs (April XX, 2001)\n";
/* A few user-configurable values. */
@@ -1434,7 +1435,7 @@
((mii_status & 0x8000) == 0 && (mii_status & 0x7800)
!= 0)) {
int mii_reg0 = tulip_mdio_read(dev, phy, 0);
int mii_advert = tulip_mdio_read(dev, phy, 4);
- int to_advert;
+ unsigned int to_advert, new_bmcr;
if (tp->mii_advertise)
to_advert = tp->mii_advertise;
@@ -1455,10 +1456,30 @@
board_idx, to_advert, phy,
mii_advert);
tulip_mdio_write(dev, phy, 4, to_advert);
}
+
/* Enable autonegotiation: some boards default to off.
*/
- tulip_mdio_write(dev, phy, 0, mii_reg0 |
- (tp->full_duplex ? 0x1100 : 0x1000)
|
-
(tulip_media_cap[tp->default_port] ? 0x2000:0));
+ if (tp->default_port == 0) {
+ new_bmcr = mii_reg0 | BMCR_ANENABLE;
+ if (new_bmcr != mii_reg0)
+ new_bmcr |= BMCR_ANRESTART;
+ }
+ /* ...or disable nway, if forcing media */
+ else
+ new_bmcr = mii_reg0 & ~BMCR_ANENABLE;
+
+ if (new_bmcr != mii_reg0)
+ tulip_mdio_write(dev, phy, MII_BMCR, new_bmcr);
+
+ if (tp->full_duplex) new_bmcr |= BMCR_FULLDPLX;
+ else new_bmcr &= ~BMCR_FULLDPLX;
+ if (tulip_media_cap[tp->default_port] & MediaIs100)
+ new_bmcr |= BMCR_SPEED100;
+ elsenew_bmcr &= ~BMCR_SPEED100;
+
+ if (new_bmcr != mii_reg0) {
+ udelay(10);
+ tulip_mdio_write(dev, phy, MII_BMCR, new_bmcr);
+ }
}
}
tp->mii_cnt = phy_idx;
Re: OOPS on 2.4.4-ac4
> > Ok, I will remove vmware and switch from the nvidia driver the nv driver from > XFree 4.3. Maybe I get the oops again. Let me know if you do. I've got some other dmfe reports I'm looking at so its quite possible that is the trigger, but this time I'll be able to know its not giant binary stuff 8) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS on 2.4.4-ac4
On 12-May-01 Alan Cox wrote: >> computer during this time.=20 >> So I don't know if this has to do with the new networkcard, the new NVIDIA >> Driver 0.9-769 I installed yesterday with XFree 4.3 or something else. The = > >> --- >> Module Size Used by >> via82cxxx_audio16800 2 (autoclean) >> soundcore 3600 2 (autoclean) [via82cxxx_audio] >> ac97_codec 8560 0 (autoclean) [via82cxxx_audio] >> NVdriver 626480 12 (autoclean) >> vmnet 16224 3 >> vmmon 18224 0 >> dmfe9408 1 (autoclean) > > You are using binary only drivers. We can't debug them (least of all a 625K > module thats almost the size of the kernel). Duplicate the problems on a > boot > that never loaded vmware or nvdriver and its interesting, otherwise take it > up with vmware and nvidia - they have our source we dont have theirs Ok, I will remove vmware and switch from the nvidia driver the nv driver from XFree 4.3. Maybe I get the oops again. Ciao, Ingo "The war has already begun, Captain. All that remains now is honor and death." -- Deeron, "Points of Departure" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.4-ac8 now with added correct EXTRAVERSION
On Sat, May 12, 2001 at 01:22:42AM +0100, Alan Cox wrote: > > Somewhere between ac5 and ac8 ipc broke, noticed that fakeroot stopped > > working, getting a function not implemented in msgget: > > > > [pid 9812] msgget(667493921, IPC_CREAT|0x180|0600) = -1 ENOSYS (Function not >implemented) > > Looks you you compiled without SYS5 ipc support yes, of course.. must have slipped on my keyboard while changing the pcmcia-config. thanks! -- //anders/g - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers/char/serial.c bug in ST16C654 detection
This fixes a bug in the autoconfig_startech_uarts function in
serial.c. The problem is that 0's are written to the baud rate
registers in order to detect an XR16C850 or XR16C854. This makes the
Exar ST16C654 go kablooey. Saving and restoring the baud rate
registers after the test fixes it.
I'm assuming that the XR16C85[04] detection works as is and doesn't
need the original baud rate restored. If I'm wrong, I'll rewrite the
patch.
-VAL
--- linux-2.4.5-pre1/drivers/char/serial.c Thu Apr 19 00:26:34 2001
+++ linux/drivers/char/serial.c Sat May 12 05:19:26 2001
@@ -3507,7 +3507,7 @@
struct serial_state *state,
unsigned long flags)
{
- unsigned char scratch, scratch2, scratch3;
+ unsigned char scratch, scratch2, scratch3, scratch4;
/*
* First we check to see if it's an Oxford Semiconductor UART.
@@ -3551,17 +3551,32 @@
* XR16C854.
*
*/
+
+ /* Save the DLL and DLM */
+
serial_outp(info, UART_LCR, UART_LCR_DLAB);
+ scratch3 = serial_inp(info, UART_DLL);
+ scratch4 = serial_inp(info, UART_DLM);
+
serial_outp(info, UART_DLL, 0);
serial_outp(info, UART_DLM, 0);
- state->revision = serial_inp(info, UART_DLL);
+ scratch2 = serial_inp(info, UART_DLL);
scratch = serial_inp(info, UART_DLM);
serial_outp(info, UART_LCR, 0);
+
if (scratch == 0x10 || scratch == 0x14) {
+ if (scratch == 0x10)
+ state->revision = scratch2;
state->type = PORT_16850;
return;
}
+ /* Restore the DLL and DLM */
+
+ serial_outp(info, UART_LCR, UART_LCR_DLAB);
+ serial_outp(info, UART_DLL, scratch3);
+ serial_outp(info, UART_DLM, scratch4);
+ serial_outp(info, UART_LCR, 0);
/*
* We distinguish between the '654 and the '650 by counting
* how many bytes are in the FIFO. I'm using this for now,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.4-ac8 now with added correct EXTRAVERSION
> Somewhere between ac5 and ac8 ipc broke, noticed that fakeroot stopped > working, getting a function not implemented in msgget: > > [pid 9812] msgget(667493921, IPC_CREAT|0x180|0600) = -1 ENOSYS (Function not >implemented) Looks you you compiled without SYS5 ipc support > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] new version of singlecopy pipe
J . A . Magallon writes: > I tried your patch on 2.4.4-ac8, and something strange happens. > Untarring linux-2.4.4 takes a little time, disk light flashes, > but no files appear on the disk (just 'Makefile', as you will see below). > Doing a separate gunzip - tar xf works fine: What platform? Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] new version of singlecopy pipe
On 05.12 J . A . Magallon wrote: > > On 05.11 Manfred Spraul wrote: > > > > Please test it. > > The kernel space part should be ok, but I know that the > > patch can cause deadlocks with buggy user space apps. > > > > I tried your patch on 2.4.4-ac8, and something strange happens. > Untarring linux-2.4.4 takes a little time, disk light flashes, > but no files appear on the disk (just 'Makefile', as you will see below). > Doing a separate gunzip - tar xf works fine: > Quoting myself, I have tried with other tar.gz files and only the first file gets extracted. With a tar.bz2 file, I get: werewolf:~/io> gtar jxf src.tar.bz2 gtar: Skipping to next header gtar: Skipping to next header gtar: Skipping to next header gtar: Skipping to next header gtar: Skipping to next header gtar: Skipping to next header gtar: Skipping to next header gtar: Skipping to next header gtar: Skipping to next header gtar: Skipping to next header gtar: Skipping to next header gtar: Skipping to next header gtar: Skipping to next header gtar: Skipping to next header gtar: Skipping to next header gtar: Skipping to next header gtar: Error exit delayed from previous errors but all files seem to be there. -- J.A. Magallon # Let the source be with you... mailto:[EMAIL PROTECTED] Linux Mandrake release 8.1 (Cooker) for i586 Linux werewolf 2.4.4-ac8 #1 SMP Sat May 12 01:16:37 CEST 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS on 2.4.4-ac4
> computer during this time.=20 > So I don't know if this has to do with the new networkcard, the new NVIDIA > Driver 0.9-769 I installed yesterday with XFree 4.3 or something else. The = > --- > Module Size Used by > via82cxxx_audio16800 2 (autoclean) > soundcore 3600 2 (autoclean) [via82cxxx_audio] > ac97_codec 8560 0 (autoclean) [via82cxxx_audio] > NVdriver 626480 12 (autoclean) > vmnet 16224 3 > vmmon 18224 0 > dmfe9408 1 (autoclean) You are using binary only drivers. We can't debug them (least of all a 625K module thats almost the size of the kernel). Duplicate the problems on a boot that never loaded vmware or nvdriver and its interesting, otherwise take it up with vmware and nvidia - they have our source we dont have theirs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.4-ac8 now with added correct EXTRAVERSION
Somewhere between ac5 and ac8 ipc broke, noticed that fakeroot stopped working, getting a function not implemented in msgget: [pid 9812] msgget(667493921, IPC_CREAT|0x180|0600) = -1 ENOSYS (Function not implemented) ac5 works, ac8 does not.. downloading ac6 and 7 now to see exactly where it broke. -- //anders/g - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] new version of singlecopy pipe
On 05.11 Manfred Spraul wrote: > > Please test it. > The kernel space part should be ok, but I know that the > patch can cause deadlocks with buggy user space apps. > I tried your patch on 2.4.4-ac8, and something strange happens. Untarring linux-2.4.4 takes a little time, disk light flashes, but no files appear on the disk (just 'Makefile', as you will see below). Doing a separate gunzip - tar xf works fine: werewolf:~/soft/kernel# gtar zxf linux-2.4.4.tar.gz werewolf:~/soft/kernel# ls linux-2.4.4 Makefile werewolf:~/soft/kernel# sync werewolf:~/soft/kernel# ls linux-2.4.4 Makefile werewolf:~/soft/kernel# gunzip linux-2.4.4.tar.gz werewolf:~/soft/kernel# tar xf linux-2.4.4.tar werewolf:~/soft/kernel# ls linux-2.4.4 COPYING MAINTAINERS REPORTING-BUGS drivers/ init/lib/ scripts/ CREDITS Makefile Rules.make fs/ ipc/ mm/ Documentation/ README arch/ include/ kernel/ net/ Some buffers get not flushed ??? If they can interact with yours, I have also applied the patches for - cache-align from Andrea (I suppose it has nothing to do with yours) - context-switches reduction by Mike Galbraith (perhaps ?) and a silly couple more (CC:=$(CC) in Makefile, missing return in aic7xxx). -- J.A. Magallon # Let the source be with you... mailto:[EMAIL PROTECTED] Linux Mandrake release 8.1 (Cooker) for i586 Linux werewolf 2.4.4-ac8 #1 SMP Sat May 12 01:16:37 CEST 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.4-ac8 doesn't work with Lite-On 82c168 PNIC rev 32
The tulip driver in 2.4.4-ac8 doesn't work with Lite-On 82c168 PNIC rev 32 in the NetGear FA310TX REV-D2. It sends BOOTP request and times out. H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Not a typewriter
I had an experience pretty close... but I never saw anything wrong with man... I have ALWAYS LOVED man it's the perfect help system IMO, and info is infuriating to me... There should be a but more documentation some places sure, but nothing is going to completely remedy that... because you'll never get everybody to keep documentation updated correctly. Sam Bingner PACAF CSS/SCHE Contractor RSIS DSN 315 449-7889 COMM808 449-7889 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, May 11, 2001 1:19 PM To: Hacksaw Cc: [EMAIL PROTECTED] Subject: Re: Not a typewriter On 05/11/2001 at 04:43:13 PM Hacksaw <[EMAIL PROTECTED]> wrote: >Well, I can't disagree. Unix's biggest turn off was the stupid command names. >It's a big reason why Unixoid systems aren't more commonplace. I only learned >it because I was stuck at a desk with a Wyse terminal. Otherwise I probably >would have played with the Autocad machines more. Once I understood the >basics, I understood the power of the system. My first exposure to Unix came in 1987 when I was assigned to write a datacomm package in C on a Unix (AIX) workstation the company had just bought. I was the only one in our shop who knew C, and no one else there had ever dealt with Unix either. (I had heard of Unix, but didn't know anything about it.) My training consisted of my boss handing me the manuals and saying, "Figure it out." For the first two weeks I absolutely HATED that system; nothing made sense, vi seemed insane, and I was stumbling blindly through the documentation (I'd never seen a permuted index before). Then suddenly something clicked, it all started to make sense, and I fell in love with it. That's why I think it's so important for people to learn the Unix mindset before trying to deal with Unix systems. It's also why I have so little patience with people who don't have the patience to work through the learning curve. >But first we need a better help system. The absolute most stupid convention of >Unix is the man command. The fact that SCCS before, and now Bash usurp the >keyword "help" is beyond the pale. I guess we'll just have to agree to disagree, because we have exactly opposite opinions on all this. I love the short, cryptic command names, and I think man is the best help system ever devised. (The GNU Info system, however, is the spawn of Satan. :-) In case you haven't guessed, I love vi, too, and use it whenever possible. If Unix (or Linux) ever gets to the point of losing things like this, I'll have no desire to use it. Wayne - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: Enable IP PNP for 2.4.4-ac8
On Fri, May 11, 2001 at 04:28:05PM -0700, David S. Miller wrote: > > H . J . Lu writes: > > 2.4.4-ac8 disables IP auto config by default even if CONFIG_IP_PNP is > > defined. Here is a patch. > > It doesn't make any sense to enable this unless parameters are > given to the kernel via the kernel command line or from firmware > settings. >From Configure.help: IP: kernel level autoconfiguration CONFIG_IP_PNP This enables automatic configuration of IP addresses of devices and of the routing table during kernel boot, based on either information supplied on the kernel command line or by BOOTP or RARP protocols. You need to say Y only for diskless machines requiring network access to boot (in which case you want to say Y to "Root file system on NFS" as well), because all other machines configure the network in their startup scripts. It works fine for 2.4.4. However, in 2.4.4-ac8, even if I select CONFIG_IP_PNP, I have to pass ip= to kernel, in addition to nfsroot=x.x.x.x:/foo/bar. With 2.4.4, I can just pass nfsroot=x.x.x.x:/foo/bar to kernel. H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
OOPS on 2.4.4-ac4
Hello, I have the following Hardware installed: Epox EP-8KTA2 with Athlon 800 onboard sound enabled with kernel driver cat /proc/pci PCI devices found: Bus 0, device 0, function 0: Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 2). Master Capable. Latency=8. Prefetchable 32 bit memory at 0xd000 [0xd3ff]. Bus 0, device 1, function 0: PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (rev 0). Master Capable. No bursts. Min Gnt=12. Bus 0, device 7, function 0: ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 64). Bus 0, device 7, function 4: Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 64). Bus 0, device 7, function 5: Multimedia audio controller: VIA Technologies, Inc. AC97 Audio Controller (rev 80). IRQ 15. I/O at 0x9c00 [0x9cff]. I/O at 0xa000 [0xa003]. I/O at 0xa400 [0xa403]. Bus 0, device 9, function 0: Unknown mass storage controller: Triones Technologies, Inc. HPT366 (rev 3). IRQ 11. Master Capable. Latency=120. Min Gnt=8.Max Lat=8. I/O at 0xa800 [0xa807]. I/O at 0xac00 [0xac03]. I/O at 0xb000 [0xb007]. I/O at 0xb400 [0xb403]. I/O at 0xb800 [0xb8ff]. Bus 0, device 10, function 0: SCSI storage controller: Adaptec AIC-7881U (rev 0). IRQ 15. Master Capable. Latency=32. Min Gnt=8.Max Lat=8. I/O at 0xbc00 [0xbcff]. Non-prefetchable 32 bit memory at 0xd800 [0xd8000fff]. Bus 0, device 13, function 0: Ethernet controller: Davicom Semiconductor, Inc. Ethernet 100/10 MBit (rev 49). IRQ 10. Master Capable. Latency=32. Min Gnt=20.Max Lat=40. I/O at 0xc000 [0xc0ff]. Non-prefetchable 32 bit memory at 0xd8001000 [0xd80010ff]. Bus 1, device 0, function 0: VGA compatible controller: nVidia Corporation Riva TnT 128 [NV04] (rev 4). IRQ 12. Master Capable. Latency=248. Min Gnt=5.Max Lat=1. Non-prefetchable 32 bit memory at 0xd400 [0xd4ff]. Prefetchable 32 bit memory at 0xd600 [0xd6ff]. I had trouble with a Networkcard with Realtek RTL 8139A Chip wich does not work proper with the via Chip. So today I changed the card with one from Fiober Line wich has a Davicom DM 9102AF Chip. After some stress test I thought this card was doing fine. Now I had to leave and prepared the computer for my Girlfried. Loggin in under her account, starting KDE 2.1.2 under Suse 7.1 and switched of the Monitor. 6 Hours later I found this oops and my girlfriend hasn't used the computer during this time. So I don't know if this has to do with the new networkcard, the new NVIDIA Driver 0.9-769 I installed yesterday with XFree 4.3 or something else. The only thing I know is, that I never had this oops before. If there is something more I can do to help to find the reason please tell me, but please more than three words, I'm no kernel Hacker, I just like to help. I included the part of /var/log/messages. I left between the May 11 17:33:44 lara -- MARK -- and May 11 17:53:44 lara -- MARK -- entry and came back at May 12 00:43:36 vmware -version VMware Workstation protocol=6 build=build-1118 product='2.0.4 build-1118' My modules: --- Module Size Used by via82cxxx_audio16800 2 (autoclean) soundcore 3600 2 (autoclean) [via82cxxx_audio] ac97_codec 8560 0 (autoclean) [via82cxxx_audio] NVdriver 626480 12 (autoclean) vmnet 16224 3 vmmon 18224 0 dmfe9408 1 (autoclean) --- ksymoops 2.4.1 on i686 2.4.4-ac4. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.4-ac4/ (default) -m /usr/src/linux/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. May 12 00:15:50 lara kernel: Unable to handle kernel paging request at virtual address 417563e8 May 12 00:15:50 lara kernel: c012ffb4 May 12 00:15:50 lara kernel: Oops: May 12 00:15:50 lara kernel: CPU:0 May 12 00:15:50 lara kernel: EIP:0010:[set_blocksize+404/544] May 12 00:15:50 lara kernel: EFLAGS: 00010a87 May 12 00:15:50 lara kernel: eax: 417563c0 ebx: ecx: c11956bc edx: May 12 00:15:50 lara kernel: esi: 417563c0 edi: c17563c0 ebp: c11956a0 esp: c356fda0 May 12 00:15:50 lara kernel: ds: 0018 es: 0018 ss:
Re: PATCH: Enable IP PNP for 2.4.4-ac8
H . J . Lu writes: > 2.4.4-ac8 disables IP auto config by default even if CONFIG_IP_PNP is > defined. Here is a patch. It doesn't make any sense to enable this unless parameters are given to the kernel via the kernel command line or from firmware settings. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PATCH: Enable IP PNP for 2.4.4-ac8
2.4.4-ac8 disables IP auto config by default even if CONFIG_IP_PNP is defined. Here is a patch. H.J. --- --- linux-2.4.4-ac8/net/ipv4/ipconfig.c.autoFri May 11 14:02:32 2001 +++ linux-2.4.4-ac8/net/ipv4/ipconfig.c Fri May 11 15:26:25 2001 @@ -100,7 +100,11 @@ */ int ic_set_manually __initdata = 0;/* IPconfig parameters set manually */ +#if defined(CONFIG_IP_PNP) +int ic_enable __initdata = 1; /* IP config enabled? */ +#else int ic_enable __initdata = 0; /* IP config enabled? */ +#endif /* Protocol choice */ int ic_proto_enabled __initdata = 0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How can I help with VIA MVP3 problems?
> Supposedly there are some problems with the VIA chipsets, but apparently it > has been better before so I wonder why it is worse now and what the plans are > regarding any improvement? Until the past few -ac releases we accidentally turned off things on the older VIA chipsets (with a performance hit) as well as the actual problem components. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Not a typewriter
On 05/11/2001 at 04:43:13 PM Hacksaw <[EMAIL PROTECTED]> wrote: >Well, I can't disagree. Unix's biggest turn off was the stupid command names. >It's a big reason why Unixoid systems aren't more commonplace. I only learned >it because I was stuck at a desk with a Wyse terminal. Otherwise I probably >would have played with the Autocad machines more. Once I understood the >basics, I understood the power of the system. My first exposure to Unix came in 1987 when I was assigned to write a datacomm package in C on a Unix (AIX) workstation the company had just bought. I was the only one in our shop who knew C, and no one else there had ever dealt with Unix either. (I had heard of Unix, but didn't know anything about it.) My training consisted of my boss handing me the manuals and saying, "Figure it out." For the first two weeks I absolutely HATED that system; nothing made sense, vi seemed insane, and I was stumbling blindly through the documentation (I'd never seen a permuted index before). Then suddenly something clicked, it all started to make sense, and I fell in love with it. That's why I think it's so important for people to learn the Unix mindset before trying to deal with Unix systems. It's also why I have so little patience with people who don't have the patience to work through the learning curve. >But first we need a better help system. The absolute most stupid convention of >Unix is the man command. The fact that SCCS before, and now Bash usurp the >keyword "help" is beyond the pale. I guess we'll just have to agree to disagree, because we have exactly opposite opinions on all this. I love the short, cryptic command names, and I think man is the best help system ever devised. (The GNU Info system, however, is the spawn of Satan. :-) In case you haven't guessed, I love vi, too, and use it whenever possible. If Unix (or Linux) ever gets to the point of losing things like this, I'll have no desire to use it. Wayne - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] adding PCI bus information to SCSI layer
> >> > > > I'm curious, though: I haven't found the mail standards that forbid > >> receivers to wrap long lines. Certainly many mail clients do it. > >> What's the relevant RFC? > > > >RFC 2822, 2.1.1. > > Thanks. It's not quite a standard yet, but it's true, it does limit > lines to 998 characters. Sort of a strange limit, but there you > are > Perhaps it's 998 so that with the \r\n end of line it rounds out to an even 1000. That limit is slightly more sensical. Steven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] adding PCI bus information to SCSI layer
At 1:32 PM -0300 2001-05-11, Ralf Baechle wrote: >On Thu, May 03, 2001 at 12:51:25AM -0700, Jonathan Lundell wrote: >> Kai Henningsen wrote: >> >What's a lot more important is that the mail standards say that this stuff >> >should not be interpreted by the receivers as needing wrapping, so >> >irregardless of good or bad design it's just plain illegal. >> > >> >If you want to support wrapping with plain text, investigate >> >format=flowed. >> >> Yes, I did that. >> > > I'm curious, though: I haven't found the mail standards that forbid >> receivers to wrap long lines. Certainly many mail clients do it. >> What's the relevant RFC? > >RFC 2822, 2.1.1. Thanks. It's not quite a standard yet, but it's true, it does limit lines to 998 characters. Sort of a strange limit, but there you are -- /Jonathan Lundell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
How can I help with VIA MVP3 problems?
I am not on this list but has followed it on Kernel Traffic. Incidentally I have a VIA MVP3 (82C59?) motherboard with an AMD K6-2 3D CPU and I haven't been too happy with the performance of 2.4.* kernels, and it includes every release of Linus' and AC's test kernels, when comparing to 2.2.16 (my reference 2.2 kernel). My benchmarks are kernel compiles and the Livid OMS DVD application that are noticeable slower. Supposedly there are some problems with the VIA chipsets, but apparently it has been better before so I wonder why it is worse now and what the plans are regarding any improvement? I would love to do something to help, ie. on the testing/bug reporting side of things. I looked in the MAINTAINERS file, but couldn't find any general maintainer for the VIA chipsets. If I know what to test and look for I expect to provide much better bug reports than this one, but a full test report would be many kilobytes of data so I thought I'd hold it off in the first posting :-) Thanks, Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Size of /proc/kcore growing over time ?
On 05.11 Martin.Knoblauch wrote: > > I ask, because I thought the size of kproc could be used to determine > the amount of physical memory. If this assumption is wrong, is there > another way to achive the goal? > #include // for get_phys_pages() #include // for getpagesize() ram = get_phys_pages()*getpagesize(); -- J.A. Magallon # Let the source be with you... mailto:[EMAIL PROTECTED] Linux Mandrake release 8.1 (Cooker) for i586 Linux werewolf 2.4.4-ac6 #1 SMP Wed May 9 14:28:00 CEST 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.4-ac8 now with added correct EXTRAVERSION
Mads Martin Jørgensen wrote: > > * Alan Cox <[EMAIL PROTECTED]> [May 11. 2001 13:18]: > > 2.4.4-ac8 > > o Tulip driver updates(Jeff Garzik) > > Networking stopped working with this kernel. I have the following > NIC: Can you define TULIP_DEBUG to 4 in drivers/net/tulip/tulip.h and e-mail me the 'dmesg' output? -- Jeff Garzik | Game called on account of naked chick Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Oops in 2.4.4-ac6, ksymoops output included
I got this oops while running 2.4.4-ac6 and trying to open a file to edit with vi. I have had this happen before while I was opening a text file but I suspect that it is just coincidence. I have included the ksymoops output for the oops and also my kernel configuration. If there are any patches or if there is any more information that anyone needs then please let me know. Thanks, Sean ksymoops info: ksymoops 2.4.1 on i686 2.4.4-ac6. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.4-ac6/ (default) -m /usr/src/linux/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Warning (read_object): no symbols in /lib/modules/2.4.4-ac6/build/drivers/pnp/pnp.o Warning (read_object): no symbols in /lib/modules/2.4.4-ac6/build/drivers/misc/misc.o Warning (read_object): no symbols in /lib/modules/2.4.4-ac6/build/drivers/media/radio/radio.o Warning (read_object): no symbols in /lib/modules/2.4.4-ac6/build/drivers/media/video/video.o Warning (read_object): no symbols in /lib/modules/2.4.4-ac6/build/drivers/media/media.o Warning (read_object): no symbols in /lib/modules/2.4.4-ac6/build/drivers/parport/driver.o Warning (read_object): no symbols in /lib/modules/2.4.4-ac6/build/crypto/crypto.o May 10 18:01:49 hehehe kernel: c0116008 May 10 18:01:49 hehehe kernel: Oops: 0002 May 10 18:01:49 hehehe kernel: CPU:0 May 10 18:01:49 hehehe kernel: EIP:0010:[release_task+24/336] May 10 18:01:49 hehehe kernel: EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 May 10 18:01:49 hehehe kernel: EFLAGS: 00013246 May 10 18:01:49 hehehe kernel: eax: 0100 ebx: d51b2000 ecx: edx: bfffe49c May 10 18:01:49 hehehe kernel: esi: c672c000 edi: 3c46 ebp: esp: c672df84 May 10 18:01:49 hehehe kernel: ds: 0018 es: 0018 ss: 0018 May 10 18:01:49 hehehe kernel: Process configure (pid: 15429, stackpage=c672d000) May 10 18:01:49 hehehe kernel: Stack: d51b2000 c0116c56 d51b2000 c672c000 May 10 18:01:49 hehehe kernel:c672c000 c672c0ac c672c0ac c672c000 0810608c bfffe468 c0106d47 May 10 18:01:49 hehehe kernel: bfffe49c 0810608c bfffe468 0072 002b May 10 18:01:49 hehehe kernel: Call Trace: [sys_wait4+790/928] [system_call+51/56] May 10 18:01:49 hehehe kernel: Call Trace: [] [] May 10 18:01:49 hehehe kernel: Code: 00 00 ff 48 04 8b 8b d4 01 00 00 51 e8 17 4d 00 00 8b 43 3c >>EIP; c0116008<= Trace; c0116c56 Trace; c0106d47 Code; c0116008 <_EIP>: Code; c0116008<= 0: 00 00 add%al,(%eax) <= Code; c011600a 2: ff 48 04 decl 0x4(%eax) Code; c011600d 5: 8b 8b d4 01 00 00 mov0x1d4(%ebx),%ecx Code; c0116013 b: 51push %ecx Code; c0116014 c: e8 17 4d 00 00call 4d28 <_EIP+0x4d28> c011ad30 Code; c0116019 11: 8b 43 3c mov0x3c(%ebx),%eax May 10 18:01:49 hehehe kernel: <1>Unable to handle kernel NULL pointer dereference at virtual address 0100 May 10 18:01:49 hehehe kernel: c0116008 May 10 18:01:49 hehehe kernel: Oops: 0002 May 10 18:01:49 hehehe kernel: CPU:0 May 10 18:01:49 hehehe kernel: EIP:0010:[release_task+24/336] May 10 18:01:49 hehehe kernel: EIP:0010:[] May 10 18:01:49 hehehe kernel: EFLAGS: 00010246 May 10 18:01:49 hehehe kernel: eax: 0100 ebx: d51b2000 ecx: edx: b3cc May 10 18:01:49 hehehe kernel: esi: c188e000 edi: 3c46 ebp: esp: c188ff84 May 10 18:01:49 hehehe kernel: ds: 0018 es: 0018 ss: 0018 May 10 18:01:49 hehehe kernel: Process init (pid: 1, stackpage=c188f000) May 10 18:01:49 hehehe kernel: Stack: d51b2000 c0116c56 d51b2000 c188e000 May 10 18:01:49 hehehe kernel:c188e000 c188e0ac c188e0ac c188e000 b3cc b3ac c0106d47 May 10 18:01:49 hehehe kernel: b3cc 0001 b3cc b3ac 0072 002b May 10 18:01:49 hehehe kernel: Call Trace: [sys_wait4+790/928] [system_call+51/56] May 10 18:01:49 hehehe kernel: Call Trace: [] [] May 10 18:01:49 hehehe kernel: Code: 00 00 ff 48 04 8b 8b d4 01 00 00 51 e8 17 4d 00 00 8b 43 3c >>EIP; c0116008<= Trace; c0116c56 Trace; c0106d47 Code; c0116008 <_EIP>: Code; c0116008<= 0: 00 00 add%al,(%eax) <= Code; c011600a 2: ff 48 04 decl 0x4(%eax) Code; c011600d 5: 8b 8b d4 01
Re: PROBLEM: 2.4.4ac7 oops, locks in init on boot
On Fri, May 11, 2001 at 09:03:30PM +0100, Alan Cox wrote: > > I'm considering it, but for AGP weirdness reasons. Have the USB bugs been > > worked out? I am highly dependant on USB. > > Only one stepping of the AMD chip had the USB funnies. AMD released the info > needed to work around it and its now in the tree. Ah, thanks Alan. I may need to consider the AMD boards seriously if I can't get the Radeon 64 working on the KT7A in the next few weeks. I'm hoping -ac7 will fix that. -- Joseph Carter <[EMAIL PROTECTED]>Free software developer Knghtbrd: we should do a quake episode :knee deep in the code": you run around shooting at bugs:) taniwha: I'll pass the idea on to OpenQuartz ;> PGP signature
Re: Not a typewriter
>If clarity is the most important consideration, then other things should be >changed as well. For instance, the command we use to search for text strings in >files should be called "textsearch." That's a lot more clear than "grep." Well, I can't disagree. Unix's biggest turn off was the stupid command names. It's a big reason why Unixoid systems aren't more commonplace. I only learned it because I was stuck at a desk with a Wyse terminal. Otherwise I probably would have played with the Autocad machines more. Once I understood the basics, I understood the power of the system. However, I was a CS major, smart, and a voracious reader. - I have often thought of an alternate naming scheme that would apply to the most basic utilities. With command completion longer names become less annoying. But first we need a better help system. The absolute most stupid convention of Unix is the man command. The fact that SCCS before, and now Bash usurp the keyword "help" is beyond the pale. >If the wording is going to be changed, then it's better to abandon the tradition I say abandon tradition when tradition doesn't serve. Arcane messages prevent understanding, arbitrary command names sometimes can't be avoided. The process is annoying at best, and painful on Linux systems where the documentation isn't unified, and is often incomplete. A beautiful example that came up on my RedHat 6.2 system: [From ppd_file_new_from_filep(3)] ENOTTY no idea what these errors are. Probably PPD parse errors. I run into things like this all the time. "Textsearch" is better than grep, except sometimes you aren't searching through text. "Search" is more general. "Find" would be even better. I wish that find had the functions of grep as well, ala the MacOS "find", which can (these days) search for files names and attributes, and also search for things inside files. >My point is that someone who sees the "typewriter" message and doesn't >understand it will have to dig a bit to find out what it means. All well and good if you have the time. If you are in a business or academic settings, the learning curve is an important part of the total cost of ownership. Ob. LKML: Error messages from the kernel should be examined with this in mind. The more clear that error message is, the less likely we'll see a question about it here. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.4-ac8 now with added correct EXTRAVERSION
This fixed the problem with unresolved symbols in nfs.o. Wayne - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.4-ac8 now with added correct EXTRAVERSION
* Alan Cox <[EMAIL PROTECTED]> [May 11. 2001 13:18]: > 2.4.4-ac8 > o Tulip driver updates(Jeff Garzik) Networking stopped working with this kernel. I have the following NIC: 02:0b.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) Subsystem: Netgear FA310TX Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- [disabled] [size=256K] -- Mads Martin Joergensen, http://mmj.dk "Why make things difficult, when it is possible to make them cryptic and totally illogic, with just a little bit more effort." -- A. P. J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Athlon possible fixes
On Sun, May 06, 2001 at 01:51:59PM +0100, Alan Cox wrote: > > There really needs to be a hardware fix... this doesn't stop some > > application having it's owne optimised code from breaking on some > > hardware (think games and similation software perhaps). > > prefetch is virtually addresses. An application would need access to /dev/mem > or similar. So the only folks I think it might actually bite are the Xserver > people. Prefetch bugs in hardware have biten Linux/68k as early as '94; a GVP SCSI HBA on the Amiga may touch areas beyond the last valid RAM address when doing DMA to the last page. Being a burned child from that time Linux/MIPS didn't use the last RAM page just to be on the safe side. Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bandwidth
On Wed, May 02, 2001 at 09:35:05AM -, mirabilos wrote: > > What you have todo is to learn how to configure your mailer to display > > headers you want. > > Not the displaying annoys me, it's the traffic. The headers usually are > less than multiple quoted sigs, though. Headers serve a technical purpose. So for example adding Received: headers is a MUST according to RFC 2822, 3.8.2: 3.8.2 Received Lines in Gatewaying When forwarding a message into or out of the Internet environment, a gateway MUST prepend a Received: line, but it MUST NOT alter in any way a Received: line that is already in the header. Similar for the other headers; basically all of them cannot be removed without loosing functionality or putting the reliability of the mail system at stake. Let me just say mail loops ... Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] adding PCI bus information to SCSI layer
On Thu, May 03, 2001 at 12:51:25AM -0700, Jonathan Lundell wrote: > >What's a lot more important is that the mail standards say that this stuff > >should not be interpreted by the receivers as needing wrapping, so > >irregardless of good or bad design it's just plain illegal. > > > >If you want to support wrapping with plain text, investigate > >format=flowed. > > Yes, I did that. > > I'm curious, though: I haven't found the mail standards that forbid > receivers to wrap long lines. Certainly many mail clients do it. > What's the relevant RFC? RFC 2822, 2.1.1. Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Patch for 2.4.4-ac7
This should fix http://boudicca.tux.org/hypermail/linux-kernel/this-week/0901.html H.J. --- linux-2.4.4-ac7/mm/filemap.c.module Fri May 11 13:32:20 2001 +++ linux-2.4.4-ac7/mm/filemap.cFri May 11 13:33:03 2001 @@ -9,6 +9,8 @@ * most "normal" filesystems (but you don't /have/ to use this: * the NFS filesystem used to do this differently, for example) */ +#include +#include #include #include #include - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Athlon possible fixes
> Ahmm, 2.4.3 doesn't work. Gives some IDE DMA timeouts on boot. Kernel w= > as > compiled with Pentium-MMX processor setting, but I don't know if that's > enough to disable the Athlon code parts (autodetected at runtime?). That sounds totally unrelated to any Athlon optimisations > So only working kernel (without noautotune) on that A7V133 machine is > RedHat's 2.4.2-2 shipped with RedHat 7.1... But that's not good either > because the system has large reiserfs volume and 2.4.2-2 has some reise= I wish I knew why the Red Hat one worked 8) Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][CFT] (updated) ext2 directories in pagecache
On Friday 11 May 2001 18:34, Andreas Dilger wrote: > Al writes: > > On Fri, 11 May 2001, Andreas Dilger wrote: > > > I've tested again, now with kdb, and the system loops in > > > ext2_find_entry() or ext2_add_link(), because there is a > > > directory with a zero rec_len. While the actual cause of this > > > problem is elsewhere, the fact that ext2_next_entry() will loop > > > forever with a bad rec_len is a bug not in the old ext2 code. > > > > No. Bug is that data ends up in pages without being validated. > > That's the real thing to watch for - if ext2_get_page() is the only > > way to get pages in cache you get all checks in one place and done > > once. > > OK, I don't think that Daniel is aware of this, I wasn't either. He > is using ext2_bread() modified to access the page cache instead of > the buffer cache. Oh yes, I'm well aware it, that's what I mean by the "bullet proofing" item on my to-do list. I don't quite agree with the idea of embedding the checking of directory entry format inside the ext2_get_page routine, it should be moved outside ext2_get_page, on basic principal. Never mind that this routine is only used to get pages of directory files, it's still not nice. Anyway, I think the thing to do is graft a similar one-time check onto ext2_bread. We can't use Al's PG_checked mechanism because we might have read only one buffer out of several on the page. > It turns out that in adding the checks for rec_len, I fixed my > original bug, but added another... Please disregard my previous > patch. In any event, I couldn't apply it due to patch giving a 'malformed' error - did you edit it after diffing? I'll wait for a revised patch - there's quite a lot of stuff in there including formatting changes, ext2 warnings, etc. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM 1.0 release decision
Andrea Arcangeli writes: > I just switched to the >=beta4 lvm IOP for all 64bit archs. The previous > one (the 2.4 mainline one) isn't feasible on the archs with 32bit > userspace and 64bit kernel (it uses long). The IOP didn't changed btw, > only the structures changed silenty. They can be converted, there is in fact initial sparc64 code to handle the existing LVM ioctls in arch/sparc64/kernel/ioctl32.c Without argument, the LVM ioctls are done in such a way that conversion is a bit difficult, but not entirely impossible. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.4-ac8 now with added correct EXTRAVERSION
ftp://ftp.linux.org.uk/pub/linux/alan/2.4-ac/ Intermediate diffs are available from http://www.bzimage.org ** ** Please note change of ftp site. ftp.kernel.org switched to using ECN and ** it seems NTL's cablemodem folks have problem firewalls between their ** Inktomi cache and the world. The -ac patches and future 2.2.20pre will be ** distributed from ftp.linux.org.uk until further notice. ** 2.4.4-ac8 o Prefetch constant copy_to_user data (Arjan van de Ven) o Update cpqarray driver - use pci dma api(Charles White) o Update cciss driver - use pci dma api (Charles White) o Enable compiled in synclink driver (Paul Fulghum) o Fix plip section conflict (Keith Owens) o Tulip driver updates(Jeff Garzik) o Frame buffer logo updates (Geert Uytterhoeven) o Update __initdata documentation (Ingo Oeser) o Linearize sunrpc buffers using GFP_KERNEL (Trond Myklebust) o C Scott Ananian has moved (C Scott Ananian) o Update get_unaligned docs (John Levon) o Fix pci pool handling on boxes that have non(Pete Zaitcev) irq safe map create/destroy o Update m68k semaphores (Geert Uytterhoeven) o Update NLS Configure.help (Nerijus Baliunas) o Clean up cyclom driver (Arnaldo Carvalho de Melo) o Further serial driver update(Jeff Garzik) o Fix typo in sched.c (Jim Freeman) o Do prefetches on wake_up_common walk(Arjan van de Ven) o Fix bootmem init problems (Andrea Arcangeli) o Fix pops on cs46xx power management (Thomas Woller) o Fix reference of freed memory in cs46xx (Christopher Kanaan) o Hopefully fix i2o scsi reset crash (me) 2.4.4-ac7 o Fix dasd off by one found by Al Viro(me) o Fix copy under cli in moxa,mxser,pcxx,riscom8 o Cleaned up serial167 formatting (no code(me) changes this patch set) o Fix missing length check in AGPgart (me) | Found by Al Viro o Fix wrong kmalloc sizes in ixj/emu10k1 (David Chan) o Fix make distclean on ramfs/tmpfs (Ingo Oeser) o Update checkconfig, Changes (Niels Jensen) o NFS mmap consistency on close fix (Andrea Arcangeli) o Fix 10 bit decode causing APM hang on a laptop (Pete Zaitcev) when using ymfpci o Reserve failure on vesa video ram is not fatal (Jordan Crouse) o Update athlon mmx copier to not prefetch off(Arjan van de Ven) the end o Fix scsi.c procfs zero termination checks (Al Viro) o And fix -EFAULT returns from it (me) o Update ibm token ring driver(Mike Phillips) o Fix sockfilter maths overflow (Al Viro) o Make dev name lookup robust to nonterminated(Al Viro) buffers o Update config.h use (Niels Jensen) o Fix xircom cardbus ethernet/modem support (Bill Nottingham) o Fix off by one buffer checks in atm_poa and (Al Viro) dasd o Clean up printks in zr36067.c (me) 2.4.4-ac6 o Revert dead swap patch pending fixes(Dave Miller) o Allow arch specific writeproc/DMA for IDE (Bjorn Wesen) o Move to aic7xxx 6.1.13 (Justin Gibbs) o Use pci_set_master on eni.c (Jeff Garzik) o Update wireless drivers, add airport(Jean Tourrihles, Benjamin Herrenschmidt) o Add new pci ids, clean up dup defines in eicon (Jeff Garzik) o Add module loader to kernel docs(Erik Mouw) o Fix wanrouter makefile bug (Arnaldo Carvalho de Melo) o Add another pair of idents to the yenta driver (Alexandr Kanevskiy) o Parport fixes for 1284 mode (Fred Barnes) o Update 8139too driver to handle wakeup bug (Jeff Garzik) o Add koi8-ru locale (Andrzej Krzysztofowicz) o Add ICH3 to the i810 audio driver (Tom Woller) o Improve (hopefully) the confusing I82365 help (me) o Fix a bug in koi8-u tables (Andrzej Krzysztofowicz) o Fix a bug in UTF8->CP1255 (Andrzej Krzysztofowicz) o Fix a bug in iso8859-13 tables (Andrzej Krzysztofowicz) o Update gdth driver to current vendor release(Achim Leubner) o
Re: Athlon possible fixes
Christian Bornträger wrote: > > Can you try and mail me if the Kernel 2.4.3 (without any ac patch) is > stable with your system even if you use autotune? "Downgrade" to this > kernel works fine for me. Ahmm, 2.4.3 doesn't work. Gives some IDE DMA timeouts on boot. Kernel was compiled with Pentium-MMX processor setting, but I don't know if that's enough to disable the Athlon code parts (autodetected at runtime?). So only working kernel (without noautotune) on that A7V133 machine is RedHat's 2.4.2-2 shipped with RedHat 7.1... But that's not good either because the system has large reiserfs volume and 2.4.2-2 has some reiserfs bugs. I really start hating IDE/ATA stuff again. - Jussi Laako -- PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B 39DD A4DE 63EB C216 1E4B Available at PGP keyservers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Latest on Athlon Via KT133A chipset solution?
Just tested the -ac7 with K7 optimizations on. I see the same behavior of oopsing right after boot: [...] Freeing unused kernel memory: 216k freed Unable to handle kernel NULL pointer dereference at virtual address [...] Just fine when I go back down to k6-3, et al, optimizations. Tyan S2380B VIA KT133A, amd 1.33ghz, regular stepping, no OC or anything. If you want more info, lemme know. Also had some USB weirdness, but I'm going to debug that a bit before I report on it. thx, -jeremy Christian Bornträger enlightened recipients with the following on 11May2001: > > Give the current -ac a spin and tell me if it works/doesnt and if not how > > it fails > > I will test it on Sunday evening, when I get back access to my Athlon. > > Again I am not sure if I had the same problem related to the > compiler-optimizations. My problems (system freeze) started with 2.4.3-ac7. > So the problem might related to the VIA-bug-workaround. > > Is there a possibility to get debugging messages or register dumps without a > second PC? Or is there a possibility to an unbuffered log write? e.g. write > kernel logs to a floppy disc unbuffered. Otherwise I am not sure, if I am > able to help you finding the problem. > Unfortunately I have only a VIA-based Athlon system and not a S/390 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.4.4ac7 oops, locks in init on boot
> I'm considering it, but for AGP weirdness reasons. Have the USB bugs been > worked out? I am highly dependant on USB. Only one stepping of the AMD chip had the USB funnies. AMD released the info needed to work around it and its now in the tree. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.4.4ac7 oops, locks in init on boot
On Fri, May 11, 2001 at 08:02:22PM +0100, Alan Cox wrote: > > If anyone has any further suggestions/patches to run 2.4.x with K7 > > chosen optimizations, I'm open to testing. > > 'Buy an AMD chipset box..' > > Seriously at this point I am out of ideas. The prefetch to far effect > explained the old athlon locks (step 1) people reported on all chipsets. It > didnt really seem to explain the problem with a few via chipset boards but I > was hopeful. I'm considering it, but for AGP weirdness reasons. Have the USB bugs been worked out? I am highly dependant on USB. -- Joseph Carter <[EMAIL PROTECTED]>Free software developer how are we going to pronounce '00 or '01 or '02 and so on? Say goodbye to the nineties, say hello to the naughties. :) PGP signature
Re: [PATCH] SMP race in ext2 - metadata corruption.
On Mon, 7 May 2001, Pavel Machek wrote: > OTOH with current way if you make mistake in kernel, fsck will not > automatically inherit it; therefore fsck is likely to work even if > kernel ext2 is b0rken [and that's fairly important] ... and by the same logics you should make fsck implement its own drivers - after all, right now b0rken driver affects both the kernel ext2 and fsck ;-) I'm not sure that fsck of fs mounted read/write is worth doing in the first place, but I'd rather do that via fs/ext2 exporting its metadata explicitly than by playing silly buggers with device/fs coherency. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-dev] Re: reiserfs, xfs, ext2, ext3
On Friday, May 11, 2001 12:07:08 PM -0700 Hans Reiser <[EMAIL PROTECTED]> wrote: > "Albert D. Cahalan" wrote: > >> Hans Reiser writes: >> >> > Tell us what to code for, and so long as it doesn't involve looking >> > up files by their 32 bit inode numbers we'll probably be happy to >> > code to it. The Neil Brown stuff is already coded for though. >> >> Next time around, when you update the on-disk format, how about >> allowing for such a thing? >> >> You could have a tree that maps from inode number to whatever >> you need to find a file. This shouldn't affect much more than >> file creation and deletion. Maybe it will allow for a more >> robust fsck as well, helping to justify the cost. >> >> It would be really nice to be able to find all filenames that >> refer to a given inode number. > > It would have a significant performance impact and use disk space. inode numbers have in the past been enough to find the object in the filesystem, and more than a few applications have counted on this. In my mind, the difference between an interesting research project and a real professional grade product is compatibility with these kinds of traditional expectations. I think reiserfs has been lucky that we've managed to work around the inode number problem so far (with help from Neil, Andi and others), but the number of hours wasted on cramming the 64bit key into various applications has been huge. It only makes a speed difference because the original format relies on it. When redoing the format for v4, this kind of thing should at least be considered. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: test -please disregard
On Fri, 11 May 2001, Matti Aarnio wrote: > *) "systems" include vger itself (it has died this week alone 4-5 times), Yikes! That's not a very good advertisement. Anything that the Linux-using public should know about? Matthew. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Latest on Athlon Via KT133A chipset solution?
> Give the current -ac a spin and tell me if it works/doesnt and if not how > it fails I will test it on Sunday evening, when I get back access to my Athlon. Again I am not sure if I had the same problem related to the compiler-optimizations. My problems (system freeze) started with 2.4.3-ac7. So the problem might related to the VIA-bug-workaround. Is there a possibility to get debugging messages or register dumps without a second PC? Or is there a possibility to an unbuffered log write? e.g. write kernel logs to a floppy disc unbuffered. Otherwise I am not sure, if I am able to help you finding the problem. Unfortunately I have only a VIA-based Athlon system and not a S/390 greetings Christian Bornträger - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Loopback TCP timer bug?
I've got a problem where a client and server stop talking to each other after around 32 minutes. The server is sending a packet to the client every minute with 4 bytes but the client is in a GUI loop and isn't receiving them. They should just build up in the Recv-Q for the client but after 32 minutes they stop going to the client and instead they stay in the Send-Q of the server. A timer is also started on the server socket so that after 15 times (tcp_retries2) of attempting to send, it returns back ETIMEDOUT and the server exits. A tcpdump shows that the server is sending the 4 byte packet every minute but that after 32 minutes, the client stops acking them. Why would it do that? This is all using localhost and the Recv-Q of the client only ends up with 124 bytes of data in it so I don't think its buffer is filling. The problem doesn't seem to exist on the 2.4.x kernels and only occurs on systems using the 2.2.x kernels. Was there a fix along the way for this? Here is the last bit of the tcpdump: 18:06:11.135201 localhost.localdomain.gds_db > localhost.localdomain.3139: P 16:20(4) ack 1 win 31072 (DF) (ttl 64, id 41071) 18:06:11.135201 localhost.localdomain.gds_db > localhost.localdomain.3139: P 16:20(4) ack 1 win 31072 (DF) (ttl 64, id 41071) 18:06:11.154090 localhost.localdomain.3139 > localhost.localdomain.gds_db: . ack 20 win 30952 (DF) (ttl 64, id 41072) 18:06:11.154090 localhost.localdomain.3139 > localhost.localdomain.gds_db: . ack 20 win 30952 (DF) (ttl 64, id 41072) 18:07:11.131571 localhost.localdomain.gds_db > localhost.localdomain.3139: P 20:24(4) ack 1 win 31072 (DF) (ttl 64, id 41073) 18:07:11.131571 localhost.localdomain.gds_db > localhost.localdomain.3139: P 20:24(4) ack 1 win 31072 (DF) (ttl 64, id 41073) 18:07:11.151759 localhost.localdomain.3139 > localhost.localdomain.gds_db: . ack 24 win 30948 (DF) (ttl 64, id 41074) 18:07:11.151759 localhost.localdomain.3139 > localhost.localdomain.gds_db: . ack 24 win 30948 (DF) (ttl 64, id 41074) 18:08:11.128095 localhost.localdomain.gds_db > localhost.localdomain.3139: P 24:28(4) ack 1 win 31072 (DF) (ttl 64, id 41075) 18:08:11.128095 localhost.localdomain.gds_db > localhost.localdomain.3139: P 24:28(4) ack 1 win 31072 (DF) (ttl 64, id 41075) 18:08:11.331289 localhost.localdomain.gds_db > localhost.localdomain.3139: P 24:28(4) ack 1 win 31072 (DF) (ttl 64, id 41076) 18:08:11.331289 localhost.localdomain.gds_db > localhost.localdomain.3139: P 24:28(4) ack 1 win 31072 (DF) (ttl 64, id 41076) 18:08:11.725170 localhost.localdomain.gds_db > localhost.localdomain.3139: P 24:28(4) ack 1 win 31072 (DF) (ttl 64, id 41077) 18:08:11.725170 localhost.localdomain.gds_db > localhost.localdomain.3139: P 24:28(4) ack 1 win 31072 (DF) (ttl 64, id 41077) 18:08:12.529711 localhost.localdomain.gds_db > localhost.localdomain.3139: P 24:28(4) ack 1 win 31072 (DF) (ttl 64, id 41078) 18:08:12.529711 localhost.localdomain.gds_db > localhost.localdomain.3139: P 24:28(4) ack 1 win 31072 (DF) (ttl 64, id 41078) 18:08:14.133679 localhost.localdomain.gds_db > localhost.localdomain.3139: P 24:28(4) ack 1 win 31072 (DF) (ttl 64, id 41079) 18:08:14.133679 localhost.localdomain.gds_db > localhost.localdomain.3139: P 24:28(4) ack 1 win 31072 (DF) (ttl 64, id 41079) 18:08:17.326826 localhost.localdomain.gds_db > localhost.localdomain.3139: P 24:28(4) ack 1 win 31072 (DF) (ttl 64, id 41080) 18:08:17.326826 localhost.localdomain.gds_db > localhost.localdomain.3139: P 24:28(4) ack 1 win 31072 (DF) (ttl 64, id 41080) 18:08:23.726980 localhost.localdomain.gds_db > localhost.localdomain.3139: P 24:28(4) ack 1 win 31072 (DF) (ttl 64, id 41081) 18:08:23.726980 localhost.localdomain.gds_db > localhost.localdomain.3139: P 24:28(4) ack 1 win 31072 (DF) (ttl 64, id 41081) 18:08:36.527097 localhost.localdomain.gds_db > localhost.localdomain.3139: P 24:28(4) ack 1 win 31072 (DF) (ttl 64, id 41082) 18:08:36.527097 localhost.localdomain.gds_db > localhost.localdomain.3139: P 24:28(4) ack 1 win 31072 (DF) (ttl 64, id 41082) -- Brad Pepers [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.4-ac7
In article <[EMAIL PROTECTED]>, >is the EXTRAVERSION set properly in Makefile? I use the http://www.bzim= >age.org >intermediate diff (chosen ~40K to ~2M) from ac6 nd I still have >2.4.4-ac6 login prompt (and Makefile says: EXTRAVERSION =3D -ac6). >From the original patch (agains vanilla 2.4.4) diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla/Make file linux.ac/Makefile --- linux.vanilla/Makefile Mon Apr 30 15:13:07 2001 +++ linux.ac/Makefile Wed May 9 21:45:31 2001 @@ -1,11 +1,18 @@ VERSION = 2 PATCHLEVEL = 4 SUBLEVEL = 4 -EXTRAVERSION = +EXTRAVERSION = -ac6 So yeah, Alan forgot to increment the Makefile I happen to make the intermediate diffs on bzimage.org by hand. If i bump it now, next patch won't apply clean. So i'll leave it like this. ;-) Danny -- Holland Hosting www.hoho.nl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs, xfs, ext2, ext3
> Does NFS server support for one of the included FSes not belong in the > kernel? or is it that a better way is possible and this ugly one should not > be included? If the latter, has anyone told Hans how to do it 'right' so he > can assign someone to the task? The patch Andi forwarded me for NFS still isnt too great but it meets the requirements in that it doesnt touch non reiserfs file systems and its fairly easy to verify that the NFS code paths are not changed for other file systems - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs, xfs, ext2, ext3
On Fri, May 11, 2001 at 05:04:10PM +0100, Alan Cox wrote: > > I think with the growing acceptance of ReiserFS in the Linux > > community, it is tiresome to have to apply a patch again and again > > just to get working NFS. 2.2 NFS horrors all over again. > > The zero copy patches were basically self contained and tested for 6 months. > The reiserfs NFS hacks are ugly as hell and dont belong in the base kernel. > There is a difference. Does NFS server support for one of the included FSes not belong in the kernel? or is it that a better way is possible and this ugly one should not be included? If the latter, has anyone told Hans how to do it 'right' so he can assign someone to the task? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Latest on Athlon Via KT133A chipset solution?
> Is there a possibility to get debugging messages or register dumps without a > second PC? Or is there a possibility to an unbuffered log write? e.g. write Not much. You can avoid running syslogk. The one unbuffered log source is the screen in text mode if not running it via syslogk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
User-mode Linux ported to ppc
User-mode Linux is now booting on PPC Linux - it can boot with a Debian root floppy image with init=/bin/sh and poke around. It mostly works, although there are still a few problems. The current patch is available from http://www.tartarus.org/~chris/user-mode-linux/, made against recent UML CVS (see http://user-mode-linux.sourceforge.net). Cheers, Chris -- Chris Emerson, obsessed Cambridge juggler E-mail: [EMAIL PROTECTED] Web page: http://www.chiark.greenend.org.uk/~cemerson/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.4.4ac7 oops, locks in init on boot
> If anyone has any further suggestions/patches to run 2.4.x with K7 > chosen optimizations, I'm open to testing. 'Buy an AMD chipset box..' Seriously at this point I am out of ideas. The prefetch to far effect explained the old athlon locks (step 1) people reported on all chipsets. It didnt really seem to explain the problem with a few via chipset boards but I was hopeful. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.4-ac7
My modules/filemap.ver has the same in it as yours. Wayne Alan Cox <[EMAIL PROTECTED]> on 05/11/2001 01:52:18 PM To: Wayne Brown/Corporate/Altec@Altec cc: [EMAIL PROTECTED] (Alan Cox), [EMAIL PROTECTED] (Marek P tlicki), [EMAIL PROTECTED] Subject: Re: Linux 2.4.4-ac7 > I always make mrproper after applying your patches, and I still got exactly the > same problem with nfs that Marek found. There were no errors or warnings during > the compile of the objects in the fs/nfs directory or the linking of nfs.o. > Curious : my build has #define __ver_filemap_fdatasyncf18ce7a1 #define filemap_fdatasync _set_ver(filemap_fdatasync) #define __ver_filemap_fdatawaitd4250148 #define filemap_fdatawait _set_ver(filemap_fdatawait) in modules/filemap.ver I'll have a look
[PATCH] new version of singlecopy pipe
I've attached a new version of the patch.
The patch is now split into 2 parts:
* add copy_user_to_user() into kernel/ptrace.c. Most code is shared
between access_process_vm() and copy_user_to_user().
* use the new function for singlecopy pipe.
Please test it.
The kernel space part should be ok, but I know that the
patch can cause deadlocks with buggy user space apps.
--
Manfred
// $Header$
// Kernel Version:
// VERSION = 2
// PATCHLEVEL = 4
// SUBLEVEL = 4
// EXTRAVERSION =
--- 2.4/fs/pipe.c Mon May 7 20:43:38 2001
+++ build-2.4/fs/pipe.c Fri May 11 19:17:45 2001
@@ -2,6 +2,9 @@
* linux/fs/pipe.c
*
* Copyright (C) 1991, 1992, 1999 Linus Torvalds
+ *
+ * Major pipe_read() and pipe_write() cleanup: Single copy,
+ * fewer schedules. Copyright (C) 2001 Manfred Spraul
*/
#include
@@ -10,6 +13,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -36,214 +41,303 @@
down(PIPE_SEM(*inode));
}
+#define ADDR_USER 1
+#define ADDR_KERNEL2
+struct pipe_pio {
+ struct list_head list;
+ int state; /* >0: still pending. 0: success. < 0:error code */
+ struct task_struct *tsk;
+ unsigned long addr;
+ size_t len;
+};
+
+static ssize_t
+pio_copy_to_user(struct inode *inode, char *ubuf, ssize_t chars)
+{
+ struct pipe_pio *pio;
+ struct mm_struct *mm;
+ ssize_t ret;
+ pio = list_entry(PIPE_PIO(*inode).next, struct pipe_pio, list);
+ mm = pio->tsk->mm;
+
+ if (chars > pio->len)
+ chars = pio->len;
+ if (pio->state == ADDR_KERNEL) {
+ /* kernel thread writes into a pipe. */
+ if(copy_to_user(ubuf, (void*)pio->addr, chars))
+ return -EFAULT;
+ } else {
+ ret = 0;
+ /* pio->tsk is within pipe_write(), we don't have to protect
+* against sudden death of that thread.
+*/
+ switch(copy_user_to_user(ubuf, mm, pio->addr, chars, 0))
+ {
+ case 0:
+ break;
+ case OTHER_EFAULT:
+ pio->state = -EFAULT;
+ goto unlink;
+ case OTHER_ENOMEM:
+ pio->state = -ENOMEM;
+ goto unlink;
+ case CUR_EFAULT:
+ return -EFAULT;
+ }
+ }
+ pio->addr += chars;
+ pio->len -= chars;
+ ret = chars;
+
+ if (!pio->len) {
+ pio->state = 0;
+unlink:
+ list_del(>list);
+ wake_up_process(pio->tsk);
+ if (!ret && list_empty(_PIO(*inode))) {
+ /*
+* Lock-up:
+* A block with a bad pointer was queued
+* by pipe_write() and got deleted.
+* The pipe was filled and is now empty
+* after reading 0 bytes ;-)
+* Wakeup to recover.
+*/
+ wake_up_interruptible(PIPE_WAIT(*inode));
+ }
+ }
+ return ret;
+}
+
static ssize_t
pipe_read(struct file *filp, char *buf, size_t count, loff_t *ppos)
{
struct inode *inode = filp->f_dentry->d_inode;
- ssize_t size, read, ret;
+ ssize_t read;
- /* Seeks are not allowed on pipes. */
- ret = -ESPIPE;
- read = 0;
+ /* pread is not allowed on pipes. */
if (ppos != >f_pos)
- goto out_nolock;
+ return -ESPIPE;
/* Always return 0 on null read. */
- ret = 0;
if (count == 0)
- goto out_nolock;
+ return 0;
- /* Get the pipe semaphore */
- ret = -ERESTARTSYS;
- if (down_interruptible(PIPE_SEM(*inode)))
- goto out_nolock;
-
- if (PIPE_EMPTY(*inode)) {
-do_more_read:
- ret = 0;
- if (!PIPE_WRITERS(*inode))
- goto out;
-
- ret = -EAGAIN;
- if (filp->f_flags & O_NONBLOCK)
- goto out;
+ down(PIPE_SEM(*inode));
- for (;;) {
- PIPE_WAITING_READERS(*inode)++;
- pipe_wait(inode);
- PIPE_WAITING_READERS(*inode)--;
- ret = -ERESTARTSYS;
- if (signal_pending(current))
+ read = 0;
+ for (;;) {
+ /* read what data is available */
+ int chars = PIPE_LEN(*inode);
+ if (chars) {
+ char *pipebuf = PIPE_BASE(*inode);
+ int offset = PIPE_START(*inode);
+ if (chars > count)
+ chars = count;
+
Re: Linux 2.4.4-ac7
> I always make mrproper after applying your patches, and I still got exactly the > same problem with nfs that Marek found. There were no errors or warnings during > the compile of the objects in the fs/nfs directory or the linking of nfs.o. > Curious : my build has #define __ver_filemap_fdatasync f18ce7a1 #define filemap_fdatasync _set_ver(filemap_fdatasync) #define __ver_filemap_fdatawait d4250148 #define filemap_fdatawait _set_ver(filemap_fdatawait) in modules/filemap.ver I'll have a look - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PROBLEM: 2.4.4ac7 oops, locks in init on boot
The ongoing saga of newer via chipsets and AMD CPU's. Please CC replies as I'm I read here via nntp. Please see my previous PROBLEM reports for hardware info. I compiled and boot 2.4.4ac7, got as far as init. Multiple oops's scrolled off the screen before I could see them. Attached is the final oops, but I have a feeling this is useless. You'll find my config and my attempts to run this oops through ksymoops at various -d levels. Ksymoops never returns from fnmatch or re_match_2, I had to ^C to get a prompt back. I would guess that has to do with eip: ... Code: Bad EIP value! HTH If anyone has any further suggestions/patches to run 2.4.x with K7 chosen optimizations, I'm open to testing. Gordon Sadler 2.4.4ac7oops.tar.gz
Re: 2.4.2 - Locked keyboard
On Fri, 11 May 2001, Alan Cox wrote: > From: Alan Cox <[EMAIL PROTECTED]> > Subject: Re: 2.4.2 - Locked keyboard > > > I changed the keyboard and looked at the keyboard plugs unsucessful= > > ly. > > > > Could this be related to a kernel bug or an userspace issue??? How = > > can I > > debug it? > > I think its kernel related. There are a few other reports of 'my computer > is fine but they keyboard stopped working' with 2.4.x. Does the box have > a ps/2 mouse ? I have the same problem (keyboard stops working) on 2.2 too. Keyboard is serial (or what's the non-ps/2 thing called?), mouse is ps/2, happens when I switch consoles. (in most cases X vs text, but not always, happened to me once right after reboot too, when switching between 2 text consoles). I can still ssh into the box and reboot it thou Greetings, Chipzz AKA Jan Van Buggenhout -- -- UNIX isn't dead - It just smells funny [EMAIL PROTECTED] -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.4-ac7
I always make mrproper after applying your patches, and I still got exactly the same problem with nfs that Marek found. There were no errors or warnings during the compile of the objects in the fs/nfs directory or the linking of nfs.o. Wayne Alan Cox <[EMAIL PROTECTED]> on 05/11/2001 12:53:03 PM To: [EMAIL PROTECTED] (Marek P tlicki) cc: [EMAIL PROTECTED] (Alan Cox), [EMAIL PROTECTED] (bcc: Wayne Brown/Corporate/Altec) Subject: Re: Linux 2.4.4-ac7 > is the EXTRAVERSION set properly in Makefile? I use the http://www.bzim= > age.org > intermediate diff (chosen ~40K to ~2M) from ac6 nd I still have > 2.4.4-ac6 login prompt (and Makefile says: EXTRAVERSION =3D -ac6). I forgot to change it > The other thing I noticed is: > /lib/modules/2.4.4-ac6/kernel/fs/nfs/nfs.o: unresolved symbol filemap_f= > datawait_Rd4250148 > /lib/modules/2.4.4-ac6/kernel/fs/nfs/nfs.o: unresolved symbol filemap_f= > datasync_Rf18ce7a1 cp .config ..; make mrproper; cp ../.config .config I suspect its an unclean build and the exports didnt get done right. At least I think I fixed these right 8) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-dev] Re: reiserfs, xfs, ext2, ext3
Hans Reiser writes: > Tell us what to code for, and so long as it doesn't involve looking > up files by their 32 bit inode numbers we'll probably be happy to > code to it. The Neil Brown stuff is already coded for though. Next time around, when you update the on-disk format, how about allowing for such a thing? You could have a tree that maps from inode number to whatever you need to find a file. This shouldn't affect much more than file creation and deletion. Maybe it will allow for a more robust fsck as well, helping to justify the cost. It would be really nice to be able to find all filenames that refer to a given inode number. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 kernel freeze for unknown reason
> I have been monitoring the memory usage constantly with the gnome > memory usage meter and noticed that as swap grows it is never freed > back up. I can kill off most of the large applications, such as The swap handling in 2.4 is somewhat hosed at the moment. > If I turn swap off all together or turn it off and back on > periodically to clear the swap before it gets full, I do not seem to > experience the lockups. That sounds right. I can give you a tiny patch that should fix the lockups and instead it will kill processes out of memory but thats obviously not the actual fix 8) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ip autoconfig with modules, kernel 2.4
On Fri, May 11, 2001 at 07:38:33PM +0100, Russell King wrote: > > As long as you can get the root server IP and path from the DHCP client, I can do that. :-) > then you mount it in a directory, and use pivot_root() to change to > that directory. Cool. > See the "Changing the root device" of Documentation/initrd.txt for more > information about this. This looks like the ticket. I will hack away at that when I can get a moment. :-) Thanx! b. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 kernel freeze for unknown reason
On Wednesday 09 May 2001 22:57, Jacky Liu wrote: > Dear All, > > I would like to post a question regarding to a problem of unknown freeze of > my linux firewall/gateway. > > Here is the hardware configuration of my machine: > > AMD K-6 233 MHz > 2theMax P-55 VP3 mobo > 64Mb RAM in a single module (PC-100) > Maxtor 6G UDMA-33 harddisk > Matrox MG-II display card w/8Mb RAM > 3Com 3C905B-TX NIC > RealTek 8129 10/100 NIC > > It's running 2.4.4 kernel (RedHat 7.1) and acting as a firewall using > Netfilter (gShield and Snort), DNS (Cache-Only DNS) and NAT gateway > (ip-masq.) for my home network. I used 3C905B-TX NIC as my internal NIC and > RealTek 8129 as my external NIC. Here is the problem: > > The machine has been randomly lockup (totally freeze) for number of times > without any traceable clue or error message. Usually the time frame between > each lockup is between 24 to 72 hours. The screen just freeze when it's > lockup (either in Console or X) and no "kernel panic" type or any error > message prompt up. All services (SSH, DNS, etc..) are dead when it's lockup > and I cannot find any useful information in /var/log/messages. I cannot > reproduce the lockup since it's totally randomly. The lockup happened > either when I was playing online game (A LOT, like getting thousands of > server status in counter-strike in a very short time frame, of NAT > traffic), surfing the web (normal traffic) or the machine was totally in > idle (lockup when I was sleeping). It was lockup this morning when I was > playing online game (when my game machine was trying to establish > connection to a game server). > > If there is any information you would like to obtain, please let me know. I > would like to receive a copy of your reply, thank you very much for your > kindly attention. > I have been experiencing these same problems since version 2.4.0. Although, I think it has improved a little in 2.4.4, it still locks up. The problem seems to be related to memory management and/or swap, and is seems to do it primarily on machines with over 128Mb of RAM. Although, I have not tested systematically enough to confirm this. I have been monitoring the memory usage constantly with the gnome memory usage meter and noticed that as swap grows it is never freed back up. I can kill off most of the large applications, such as netscape, xemacs, etc, and little or no memory and swap will be freed. Once swap is full after a few days, my machine will lock up. If I turn swap off all together or turn it off and back on periodically to clear the swap before it gets full, I do not seem to experience the lockups. I am running on an AMD K6-400 with 256 Mb RAM but we have experienced these problems with various other machines as well. I hope this information is helpfull in tracking down the problem. The features of the 2.4.x kernels are great and I believe all the kernel developers have done a fantastic job! However, I am disappointed that we are now on the forth 2.4.x kernel version and such as serious problem that has been there since 2.4.0 still exists. This is pretty much a show stopper for having a production machine. In the past when I was running on 2.0.3x kernels, I boasted to everybody about how rock solid Linux was and I was able to run for 5 months without a single reboot or problem, but for the last year or more I have not had much better uptime than certain other commercial operating systems. As important as the new features are, stability should be top priority for production systems. I apologize if this sounds a bit like a rant but I feel that ever since the 2.2.x kernel series, the Linux kernel community has veered away from it's original philosophy of only releasing stable kernels with even numbered versions. In fact, I have seen several even numbered kernels released with far less stability than most of the odd numbered development kernels. - Vincent - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.4ac4] Kernel crash while unmounting CD: cause andsolution
At 7:24 PM +0200 2001-05-11, Andreas Hartmann wrote: > > [1.] One line summary of the problem: >> >> Kernel panic when trying to unmount a ide-scsi cdrom. > >The problem was a not properly working cd-rw-device. I cleaned the optical >lens - and the cd-rw-device is working like at the beginning of its days. >With the same CD's which it doesn't want to burn and which causes the crash >before! Not that a dirty CD lens should be able to cause a panic -- /Jonathan Lundell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Not a typewriter
On 05/11/2001 at 12:03:43 PM Joel Jaeggli <[EMAIL PROTECTED]> wrote: >it's not clear to me that that textsearch is a more accurate description >than Get Regular ExPression It's not more accurate. But Hacksaw's original point was that a new user would not know what "not a typewriter" meant. My point was that a newbie wouldn't be likely to guess that "grep" means "search for text" either; in both cases he'd have to look it up if he'd never seen it before. BTW, grep does not stand for "Get Regular ExPression." It comes from an often-used command in the ed (and ex and vi) editor: g/re/p. The "g" means "global," the "re" is a regular expression, and the "p" means "print." So to search for all lines containing the word "foo" in a file you were editing, you would type g/foo/p. This was such a useful function that it was packaged in a standalone program that could be used to search multiple files. Wayne - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ip autoconfig with modules, kernel 2.4
On Fri, May 11, 2001 at 11:13:00AM -0700, Brian J. Murrell wrote: > I should have given more information though. My goal is actually to > NFSRoot the machine being booted. I could not determine a way to get > the "root path" attribute given by the dhcp/bootp server from > userspace back to the kernel so that it can > "change_root()/mount_root()" with it. I seem to recall there was a > proc interface for doing this at one time (in the 2.2 kernel) but it > seemed to have went away. As long as you can get the root server IP and path from the DHCP client, then you mount it in a directory, and use pivot_root() to change to that directory. See the "Changing the root device" of Documentation/initrd.txt for more information about this. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Backport of 2.4 ptrace flag to 2.2
> Alan Cox <[EMAIL PROTECTED]> writes: > > The preferable one for performance is certainly to backport the > > 2.4 changes This patch against stock 2.2.19 is a backport of the task structure ptrace flag of Linux 2.4. It is available at http://www.cs.wisc.edu/~zandy/ptrace As we reported a couple weeks ago, under Linux 2.2 ptrace can globally corrupt the FPU on SMPs. Linus identified the problem as a race between ptrace and the FPU trap handler over the process flags. The ptrace flag introduced in 2.4 eliminates the race. This port is faithful to the 2.4 design. Essentially it: - Adds a new variable `ptrace' to the task structure; - Adds new constants for this variable (PT_PTRACED etc.) and removes the corresponding old ones (PF_PTRACED etc.); - Replaces every ptrace-context reference to `flags' with a reference to `ptrace', and updates the constants used accordingly; - Updates ptrace offset constants, loads, and comparisons in assembly files. The patch is complete for all platforms except ARM. On ARM, I didn't understand the meaning of the offset constants used in the assembly, so I didn't try to fix them. The patch does include the necessary changes to C files on ARM. We have applied (cleanly), compiled (cleanly) and tested the patch on an x86 SMP, one of the same ones on which we saw FPU corruption. We have verified that FPU corruption cannot be produced, and that gdb and strace still function. We have not tested any other platform. Please direct any questions or problems with the patch to Victor Zandy <[EMAIL PROTECTED]>. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ip autoconfig with modules, kernel 2.4
On Fri, 11 May 2001, Brian J. Murrell wrote: > If there were a way to tell the kernel, from userspace, for > change_root()/mount_root() where the nfsroot path was, yes. I have > been hunting through all of the (nfs) root mount code and I don't see > it. It looks like it can be set either on the command line, or by the > kernel implementation of bootp. Am I missing it somewhere? Doesn't the pivot_root do just that in 2.4? Not that I have used it or anything. Peter -- Peter Svensson ! Pgp key available by finger, fingerprint: <[EMAIL PROTECTED]>! 8A E9 20 98 C1 FF 43 E3 07 FD B9 0A 80 72 70 AF <[EMAIL PROTECTED]> ! Remember, Luke, your source will be with you... always... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fixes against 2.4.4-ac6
On Fri, 11 May 2001, Marcelo Tosatti wrote: > Hi, > > The following patch addresses two issues: > > > - Buffer cache pages in the inactive lists are not getting their age > increased if they get touched by getblk (which will set the referenced bit > on the page). page_launder() simply cleans the referenced bit on such > pages and moves them to the active list. To resume: buffercache pages > suffer more pressure from VM than pagecache pages. That is horrible for > performance. > > > - When there is no memory available on the system for normal allocations > (GFP_KERNEL), the tasks may loop in try_to_free_pages() (which is here > called by __alloc_pages()) without blocking: > > - GFP_BUFFER allocations will _never_ block on IO inside > try_to_free_pages(). They will keep looping inside __alloc_pages() > until they get a free page. > > - __GFP_IO|__GFP_WAIT allocations may not find any way to block on > IO inside try_to_free_pages() in case we already have other tasks > inside there (kswapd will be there in such condition, for sure). Ah, one subtle issue here: if they loop, they'll probably bump memory_pressure a lot. That will result in a bigger inactive target, which means aggressive aging. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Latest on Athlon Via KT133A chipset solution?
> I just ran into this last night (I thought all the Athlon chipset bugs had > been fixed in 2.4.4 prior to last night). Nope.. > Anyway, just requesting status, and I'll gladly offer any testing help > that's needed. Give the current -ac a spin and tell me if it works/doesnt and if not how it fails - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ip autoconfig with modules, kernel 2.4
On Thu, May 10, 2001 at 06:00:39PM +0100, Russell King wrote: > > Hmm, if you've got userspace up and running, and loaded kernel > modules using insmod, then what's wrong about running a dhcp, > bootp or rarp client from userspace? In theory, and for just ip configuration, nothing. I should have given more information though. My goal is actually to NFSRoot the machine being booted. I could not determine a way to get the "root path" attribute given by the dhcp/bootp server from userspace back to the kernel so that it can "change_root()/mount_root()" with it. I seem to recall there was a proc interface for doing this at one time (in the 2.2 kernel) but it seemed to have went away. > You can then drop the > kernel space IP autoconfiguration code. If there were a way to tell the kernel, from userspace, for change_root()/mount_root() where the nfsroot path was, yes. I have been hunting through all of the (nfs) root mount code and I don't see it. It looks like it can be set either on the command line, or by the kernel implementation of bootp. Am I missing it somewhere? b. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Latest on Athlon Via KT133A chipset solution?
I noticed discussion of the various Via KT133A chipset problems related to Athlon optimized kernels has trailed off. Are people successfully using the patch that Alan Cox posted, or are there still problems? I just ran into this last night (I thought all the Athlon chipset bugs had been fixed in 2.4.4 prior to last night). Anyway, just requesting status, and I'll gladly offer any testing help that's needed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-dev] Re: reiserfs, xfs, ext2, ext3
Alan Cox wrote: > > Are you referring to Neil Brown's nfs operations patch as being as ugly as > > hell, or something else? Just want to understand what you are saying before > > arguing. > > Andi has sent me some stuff to look at. He listed four implementations and I've > only seen two of them did you see an implementation which adds operations to VFS and is written by Neil Brown (with reiserfs portions by Chris and Nikita)? > > > > NFS is ugly as hell, and we just try to conform to whatever is the latest trend > > expected to be accepted since I really don't care so long as it works and > > doesn't uglify ReiserFS more than necessary. If you have another approach, one > > that is less ugly, please let us know. This is the first I have heard someone > > Oh believe me we agree in great detail where the -problem- is. Unfortunately > the spec is kind of stuck. Its finding a minimally invasive solution for 2.4 > pending fixing it properly in 2.5 > > Alan Tell us what to code for, and so long as it doesn't involve looking up files by their 32 bit inode numbers we'll probably be happy to code to it. The Neil Brown stuff is already coded for though. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ATAPI failure in 2.4.4, not in 2.2.17 (UPDATE)
Hi,
I upgraded from kernel 2.2.17 to 2.4.4. I used "make oldconfig" to be sure I
had as many of the prior settings as possible. Didn't change any of the old
settings. I am running under RedHat 6.2. And, yes, I did all the updates
required
to go to the 2.4.4 kernel.
I use a Seagate ATAPI tape drive, model STT2A.
I have no problems in 2.2.17 doing IDE tape backups using dump, restore, and mt.
In kernel 2.4.4, I get the following repeatable scenarios (which all work in
2.2.17):
* In a full tape dump of about 50MB or so, everything goes smoothly. No errors.
* In a full tape dump of a little over 1GB (to a 10GB tape), I get the following
errors
immediately after the backup completes and I try to write a file mark with "mt":
May 9 16:50:49 isaiah kernel: ide-tape: Reached idetape_chrdev_open
May 9 16:52:05 isaiah kernel: hdd: irq timeout: status=0xd0 { Busy }
May 9 16:52:05 isaiah kernel: hdd: ATAPI reset complete
May 9 16:52:05 isaiah kernel: ide-tape: Couldn't write a filemark
May 9 16:52:06 isaiah kernel: ide-tape: Reached idetape_chrdev_open
May 9 16:54:06 isaiah kernel: ide-tape: ht0: DSC timeout
May 9 16:54:06 isaiah kernel: hdd: ATAPI reset complete
May 9 16:54:06 isaiah kernel: ide-tape: ht0: I/O error, pc = 10, key = 2, asc
= 4,
ascq = 1
May 9 16:54:06 isaiah kernel: ide-tape: ht0: I/O error, pc = 34, key = 2, asc
= 4,
ascq = 1
* In a full tape dump of between 6GB and 7GB, the backup completes, I
successfully write a tape file mark with "mt", rewind, then attempt to compare.
I get:
May 9 04:21:18 isaiah kernel: ide-tape: Reached idetape_chrdev_open
May 9 04:22:35 isaiah kernel: ide-tape: bh == NULL in
idetape_copy_stage_to_user
May 9 04:22:35 isaiah kernel: ide-tape: bh == NULL in
idetape_copy_stage_to_user
May 9 04:22:36 isaiah kernel: ide-tape: Reached idetape_chrdev_open
I also tried SCSI emulation mode (something I didn't have to do in 2.2.17)
and it didn't work either. In SCSI emulation mode, my CD-ROM drive worked
OK in SCSI emulation, but the tape drive still did not work. When I tried:
mt -f /dev/st0 rewind
I got the following errors:
May 10 07:49:33 isaiah kernel: st0: Error with sense data: [valid=0] Info
fld=0x0,
Current st09:00: sense key Illegal Request
May 10 07:49:33 isaiah kernel: Additional sense indicates Invalid command
operation code
I've reverted back to 2.2.17 kernel just so I can do successful IDE tape
backups until I can get this problem with 2.4.4 resolved.
Any helpful input appreciated. Please reply directly, as I'm not a member
of this list. If I'm not stating the problem clearly, or if I haven't provided
enough data, please let me know.
Thanks,
Mark Bratcher
begin:vcard
n:Bratcher;Mark
tel;fax:716/288-4604
tel;work:716/288-7220
x-mozilla-html:FALSE
url:www.tpr.com
org:Torrey Pines Research
version:2.1
email;internet:[EMAIL PROTECTED]
title:Director of Software Development
adr;quoted-printable:;;565 Blossom Road=0D=0ASuite A;Rochester;New York;14610;USA
x-mozilla-cpt:;19472
fn:Bratcher, Mark
end:vcard
Re: Linux 2.4.4-ac7
> is the EXTRAVERSION set properly in Makefile? I use the http://www.bzim= > age.org > intermediate diff (chosen ~40K to ~2M) from ac6 nd I still have > 2.4.4-ac6 login prompt (and Makefile says: EXTRAVERSION =3D -ac6). I forgot to change it > The other thing I noticed is: > /lib/modules/2.4.4-ac6/kernel/fs/nfs/nfs.o: unresolved symbol filemap_f= > datawait_Rd4250148 > /lib/modules/2.4.4-ac6/kernel/fs/nfs/nfs.o: unresolved symbol filemap_f= > datasync_Rf18ce7a1 cp .config ..; make mrproper; cp ../.config .config I suspect its an unclean build and the exports didnt get done right. At least I think I fixed these right 8) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs, xfs, ext2, ext3
> Are you referring to Neil Brown's nfs operations patch as being as ugly as > hell, or something else? Just want to understand what you are saying before > arguing. Andi has sent me some stuff to look at. He listed four implementations and I've only seen two of them > NFS is ugly as hell, and we just try to conform to whatever is the latest trend > expected to be accepted since I really don't care so long as it works and > doesn't uglify ReiserFS more than necessary. If you have another approach, one > that is less ugly, please let us know. This is the first I have heard someone Oh believe me we agree in great detail where the -problem- is. Unfortunately the spec is kind of stuck. Its finding a minimally invasive solution for 2.4 pending fixing it properly in 2.5 Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] VM fixes against 2.4.4-ac6
Hi,
The following patch addresses two issues:
- Buffer cache pages in the inactive lists are not getting their age
increased if they get touched by getblk (which will set the referenced bit
on the page). page_launder() simply cleans the referenced bit on such
pages and moves them to the active list. To resume: buffercache pages
suffer more pressure from VM than pagecache pages. That is horrible for
performance.
- When there is no memory available on the system for normal allocations
(GFP_KERNEL), the tasks may loop in try_to_free_pages() (which is here
called by __alloc_pages()) without blocking:
- GFP_BUFFER allocations will _never_ block on IO inside
try_to_free_pages(). They will keep looping inside __alloc_pages()
until they get a free page.
- __GFP_IO|__GFP_WAIT allocations may not find any way to block on
IO inside try_to_free_pages() in case we already have other tasks
inside there (kswapd will be there in such condition, for sure).
To address this issues, I've changed the __alloc_pages() loop to act as
following:
for normal allocations we sleep on the kswapd wait queue _only_ if not
able to make any progress with try_to_free_pages.
for GFP_BUFFER allocations we fail in case we're not able to make progress
ourselves (try_to_free_pages() returns zero in that case).
create_buffers() is able to deal with that nicely. (it sleeps until there
are "enough" free buffer_head's available)
Comments (especially about the second issue) are welcome.
And here is the patch:
diff -Nur --exclude-from=exclude linux.orig/include/linux/swap.h
linux/include/linux/swap.h
--- linux.orig/include/linux/swap.h Fri May 11 11:17:25 2001
+++ linux/include/linux/swap.h Fri May 11 11:21:26 2001
@@ -125,7 +125,7 @@
extern int page_launder(int, int);
extern int free_shortage(void);
extern int inactive_shortage(void);
-extern void wakeup_kswapd(void);
+extern void wakeup_kswapd(int);
extern int try_to_free_pages(unsigned int gfp_mask);
/* linux/mm/page_io.c */
diff -Nur --exclude-from=exclude linux.orig/mm/page_alloc.c linux/mm/page_alloc.c
--- linux.orig/mm/page_alloc.c Fri May 11 11:17:19 2001
+++ linux/mm/page_alloc.c Fri May 11 11:20:31 2001
@@ -364,7 +364,7 @@
* - if we don't have __GFP_IO set, kswapd may be
* able to free some memory we can't free ourselves
*/
- wakeup_kswapd();
+ wakeup_kswapd(0);
if (gfp_mask & __GFP_WAIT) {
__set_current_state(TASK_RUNNING);
current->policy |= SCHED_YIELD;
@@ -444,9 +444,21 @@
*the inactive clean list. (done by page_launder)
*/
if (gfp_mask & __GFP_WAIT) {
- memory_pressure++;
- try_to_free_pages(gfp_mask);
- goto try_again;
+ /*
+* In case we fail doing any progress freeing pages,
+* wait for kswapd if possible.
+*/
+ if (try_to_free_pages(gfp_mask))
+ goto try_again;
+ else if (gfp_mask & __GFP_IO) {
+ wakeup_kswapd(1);
+ memory_pressure++;
+ goto try_again;
+ } else
+ /*
+* This is a GFP_BUFFER allocation.
+*/
+ return NULL;
}
}
diff -Nur --exclude-from=exclude linux.orig/mm/vmscan.c linux/mm/vmscan.c
--- linux.orig/mm/vmscan.c Fri May 11 11:17:19 2001
+++ linux/mm/vmscan.c Fri May 11 13:21:06 2001
@@ -350,7 +350,7 @@
}
/* Page is or was in use? Move it to the active list. */
- if (PageTestandClearReferenced(page) || page->age > 0 ||
+ if (PageReferenced(page) || page->age > 0 ||
(!page->buffers && page_count(page) > 1)) {
del_page_from_inactive_clean_list(page);
add_page_to_active_list(page);
@@ -461,7 +461,7 @@
}
/* Page is or was in use? Move it to the active list. */
- if (PageTestandClearReferenced(page) || page->age > 0 ||
+ if (PageReferenced(page) || page->age > 0 ||
(!page->buffers && page_count(page) > 1) ||
page_ramdisk(page)) {
del_page_from_inactive_dirty_list(page);
@@ -1003,6 +1003,7 @@
recalculate_vm_stats();
}
+ wake_up_all(_done);
run_task_queue(_disk);
/*
@@ -1033,10 +1034,33 @@
}
}
-void wakeup_kswapd(void)
+void wakeup_kswapd(int block)
{
- if (current !=
Re: Linux 2.4.4-ac7
On Friday, May, 2001-05-11 at 15:59:16, Alan Cox wrote: > >ftp://ftp.linux.org.uk/pub/linux/alan/2.4-ac/ > >Intermediate diffs are available from > http://www.bzimage.org > > ** > ** Please note change of ftp site. ftp.kernel.org switched to using ECN and > ** it seems NTL's cablemodem folks have problem firewalls between their > ** Inktomi cache and the world. The -ac patches and future 2.2.20pre will be > ** distributed from ftp.linux.org.uk until further notice. > ** > > 2.4.4-ac7 is the EXTRAVERSION set properly in Makefile? I use the http://www.bzimage.org intermediate diff (chosen ~40K to ~2M) from ac6 nd I still have 2.4.4-ac6 login prompt (and Makefile says: EXTRAVERSION = -ac6). The other thing I noticed is: depmod depmod: *** Unresolved symbols in /lib/modules/2.4.4-ac6/kernel/fs/nfs/nfs.o modprobe nfs /lib/modules/2.4.4-ac6/kernel/fs/nfs/nfs.o: unresolved symbol filemap_fdatawait_Rd4250148 /lib/modules/2.4.4-ac6/kernel/fs/nfs/nfs.o: unresolved symbol filemap_fdatasync_Rf18ce7a1 /lib/modules/2.4.4-ac6/kernel/fs/nfs/nfs.o: insmod /lib/modules/2.4.4-ac6/kernel/fs/nfs/nfs.o failed /lib/modules/2.4.4-ac6/kernel/fs/nfs/nfs.o: insmod nfs failed I don't use it, must've checked it in by mistake. Nevertheless I report :-) regards and bye -- Marek Ptlicki <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pci_pool_free from IRQ
> How about this (with documentation fixes by David-B): Actually I'd be just as happy to call the ARM pci_free_consistent() behavior (BUG in_interrupt) the problem. Particularly if that ARM patch works OK! I've gotten success reports with pci_pool from folk using about half the architectures in linux/arch, and only ARM showed this particular problem. It appears there's no real need to update the interface spec to accomodate ARM. That means the doc fixes are simpler: in DMA-mapping.txt just clarify that some routines may be called in_interrupt (currently unspecified), and the pci.txt change about pci_device.remove() (agreed to by both Alan and DaveM, appended). - Dave > diff -ur -X dontdiff linux-2.4.4/Documentation/pci.txt >linux-2.4.4-niph/Documentation/pci.txt > --- linux-2.4.4/Documentation/pci.txt Sun Sep 17 09:45:06 2000 > +++ linux-2.4.4-niph/Documentation/pci.txt Thu May 10 12:33:03 2001 > @@ -60,8 +60,8 @@ > remove Pointer to a function which gets called whenever a device > being handled by this driver is removed (either during > deregistration of the driver or when it's manually pulled > - out of a hot-pluggable slot). This function can be called > - from interrupt context. > + out of a hot-pluggable slot). This function always gets > + called from process context, so it can sleep. > suspend, Power management hooks -- called when the device goes to > resume sleep or is resumed. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: test -please disregard
On Fri, May 11, 2001 at 06:23:25PM +0100, Matthew Kirkwood wrote: > On Fri, 11 May 2001, Matti Aarnio wrote: > > > *) "systems" include vger itself (it has died this week alone 4-5 times), > > Yikes! That's not a very good advertisement. Anything > that the Linux-using public should know about? Well, yes. At about 03:00 UTC on saturnday, May the 12th, a new box takes over. Unfortunately I don't have a clue as to why it has been failing, but the kernel is a bit old... Linux vger.redhat.com 2.2.12-20 #1 Mon Sep 27 10:40:35 EDT 1999 i686 unknown > Matthew. /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
