ASUS CUV4X-D Dual CPU's - Failure to boot...
Dear Kernel People, A friend of mine has a new PC with an ASUS CUV4X-D motherboard and dual 1GHZ PIII's. We have installed RedHat 7.1. The original RedHat SMP kernel (2.4.2) did not boot; it froze with some complaints about APIC. The backup single processor kernel 2.4.2 booted o.k., however. The upgraded kernel from RedHat (2.4.3) also refused to boot properly - the boot up will start and the screen will then go blank before I can discern any informative messages. I also downloaded the latest 2.4.6 kernel which had the identical problem, and then I also applied the latest Alan-Cox patch for 2.4.6 which did not solve the problem. The 2.4.6 kernel will boot when only a single processor is used, however. The system is fairly basic - no sound card, ADAPTEC SCSI card (nothing attached for now), 1 GB PC133 RAM, 2 60 GB IDE Harddrives (1 Maxtor, 1 IBM), CD and CDRW, GeFORCE 2 MX video card, 3Com 3c59x ethernet and not much else. Specs for the motherboard are at: http://www.asus.com.tw/Products/Motherboard/pentiumpro/cuv4x-d/index.html Any idea as to how we might get the dual processors to work? My next plan is to compile the kernel without the Pentium III optimizations... Thanks, B.D. -- % Brian Dushaw Applied Physics Laboratory University of Washington 1013 N.E. 40th Street Seattle, WA 98105-6698 (206) 685-4198 (206) 543-1300 (206) 543-6785 (fax) [EMAIL PROTECTED] Web Page: http://staff.washington.edu/dushaw/index.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/
Re: OOPS (kswapd) in 2.4.5 and 2.4.6
On Fri, 06 Jul 2001, Andrew Morton wrote:
> Henry wrote:
> >
> > ...
> > Dual-cpu pentium 233 (intel) with 128MB RAM and more than double that swap.
> >
> > ...
> > Unable to handle kernel NULL pointer dereference at virtual address 0008
> > c01b4227
> > *pde =
> > Oops:
> > CPU:0
> > EIP:0010:[]
> > Using defaults from ksymoops -t elf32-i386 -a i386
> > EFLAGS: 00010207
> > eax: 0001 ebx: ecx: 00c0 edx: c12c49c0
> > esi: c12d3f4c edi: 0001 ebp: c0d0f2a0 esp: c12d3ee0
> > ds: 0018 es: 0018 ss: 0018
> > Process kswapd (pid: 3, stackpage=c12d3000)
> > Stack: c12d3f4c c12d3f4c c01330cb 0001 001c4300 c1203048
> > 0028 c0129752 0001 c1203048 0305 c12d3f48 1000
> >001c4300 c1203048 0028 c12d3f48 1000 1c43
> > Call Trace: [] [] [] [] [] [ > 0128b1d>] []
> >[] []
> > Code: 0f b7 43 08 66 c1 e8 09 0f b7 f0 8b 43 18 a8 04 75 19 68 a7
> >
> > >>EIP; c01b4227<=
> > Trace; c01330cb
> > Trace; c0129752
> > Trace; c0106cec
> > Trace; c012981f
> > Trace; c012a4e8
> > Trace; c0128b1d
> > Trace; c01293f5
> > Trace; c0129486
> > Trace; c01054cc
>
> There does appear to be an SMP race in brw_page() which can cause
> this - end_buffer_io_async() unlocks the page, try_to_free_buffers()
> zaps the buffer_head ring and brw_page() gets a null pointer. But
> gee, it's unlikely unless you have super-fast disks and/or something
> which has a super-slow interrupt routine.
>
> Could you please provide a description of your hardware lineup?
>
> And could you please test 2.4.6 with this patch?
>
> --- linux-2.4.6/fs/buffer.c Wed Jul 4 18:21:31 2001
> +++ lk-ext3/fs/buffer.c Fri Jul 6 18:25:00 2001
> @@ -2181,8 +2181,9 @@ int brw_page(int rw, struct page *page,
>
> /* Stage 2: start the IO */
> do {
> + struct buffer_head *next = bh->b_this_page;
> submit_bh(rw, bh);
> - bh = bh->b_this_page;
> + bh = next;
> } while (bh != head);
> return 0;
> }
Howzit Andrew
So far, so good. There has not been a single oops on the two principle
servers I patched.
uptime1:8:04am up 18:22, 1 user, load average: 0.09, 0.15, 0.11
uptime2:8:04am up 18:25, 1 user, load average: 0.15, 0.20, 0.15
Andrew my china, you are the _MAN_! We should know by monday afternoon
(the monday morning/midday crunch should provide some valuable
feedback).
Cheers
Henry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Why Plan 9 C compilers don't have asm("")
I replied to davem at length but I think I forgot to "reply to all recipients". The gist of it is Forth code density is so high on Forth hardware that things like icaches aren't as important, and the factors involved are entirely different. Like high-performance Forth engines are tiny and draw negligible current. Two URL's... http://forth.gsfc.nasa.gov/ http://www.mindspring.com/chipchuck/forth.html Rick Hohensee www.clienux.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/
What's the status of kernel PNP?
I just noticed that 2.4.6-ac1 parport won't compile (well, link) without the kernel PnP stuff configured. So I tried turning it on. It prints a line saying that it found my modem at boot time, but doesn't actually configure it, so I have to run isapnp anyway if I want to use it. Okay, RTFM time... Documentation/isapnp.txt doesn't say anything about boot time (only /proc/isapnp usage after boot and some function call interfaces for kernel programming that are hard to follow). kernel-parameters.txt gives a hint, although it required reading the source code to figure out what to pass as "isapnp=" to turn verbose up. A lot of google searching comes up with a lot of stale data but the only 2.4-relevant kernel ISAPNP howto is written in Japanese. Lots of stuff describes it as a feature in the 2.4 kernels, but I can't find anything on how to use it. MAINTAINERS claims that it's maintained, but the web page is down (the whole site has moved, and /~pnp doesn't exist on the new site) and the only mailing list archives I can find for pnp-devel (at geocrawler) doesn't have any updates since the year 2000 - and those are all spam. I'm a little suspect about that maintained status, although I haven't written the maintainer yet. But the upshot of all of this is that I can't figure out WTF to do with this "feature", since I haven't noticed it actually doing anything except taking up kernel memory. On another machine, with an ISA PCMCIA adapter, which works with isapnp and David Hinds' PCMCIA package, but if I try to use the 2.4 cardbus code, it fails to probe the PCMCIA adapter, apparently because the PnP code again didn't set it up. (And there's no obvious way to force a re-probe after boot unless I build the whole thing as a module.) Again, the PnP code cheerfully points out that the PCMCIA adpater exists, but doesn't appear to grasp the concept that I didn't put the adapter into the machine because it looks pretty. Can someome point me at TFM or some other source of information? I'd be much obliged. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
device plugging
Why do we need a dummy req for plugging. As i understood only thing plugging does is to, on arrival of new req if the dev queue is empty, puts a dummy req on the queue, and schedules the unplug routine on tq_disk, which on being scheduled calls the strategy routine. So we can as well put the new req on the queue without dummy req. If i'm incorrect please explain what's exact process and the reason Please cc the response to [EMAIL PROTECTED] as i'm not subscribed. thanks http://mail.indiainfo.com First you had 10MB of free mail space. Now you can send mails in your own language !!! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Does kernel require IDE enabled in BIOS to access HD, FS errors?
Hi,
I have a SMP P166 system that has been running for years with an AIC7xxx SCSI card as
opposed to the native IDE interface. The BIOS has the IDE 0,1,2,3 set to .
Running out of disk space I installed one of the original IDE drives. The kernel
booted and ID'd the drive correctly. Kernel version 2.4.5/6 behave the same.
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
CMD646: IDE controller on PCI bus 00 dev 10
CMD646: chipset revision 1
CMD646: not 100% native mode: will probe irqs later
CMD646: chipset revision 0x01, MultiWord DMA Limited, IRQ workaround enabled
CMD646: simplex device: DMA disabled
ide0: CMD646 Bus-Master DMA disabled (BIOS)
CMD646: simplex device: DMA disabled
ide1: CMD646 Bus-Master DMA disabled (BIOS)
hdb: CD-ROM CDU76E, ATAPI CD/DVD-ROM drive
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
hdc: WDC AC2850F, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hdc: 1667232 sectors (854 MB) w/64KiB Cache, CHS=1654/16/63
hdb: packet command error: status=0x51 { DriveReady SeekComplete Error }
hdb: packet command error: error=0x44
hdb: ATAPI 4X CD-ROM drive, 256kB Cache
Uniform CD-ROM driver Revision: 3.12
Partition check:
hdc: [PTBL] [827/32/63] hdc1
However I can't boot from the SCSI drives if the IDE HD is enabled due to deficiencies
in the BIOS... boot "A: then C:" or "C: then A:" are the only choices, if neither are
present the system boots from the SCSI card, otherwise it fails to boot.
PROBLEM: cannot reliably R/W to the HD unless the BIOS is set to recognize.
I consistently see MD5SUM errors and FS corruption and other strange FS symptoms
when the BIOS is set to for the drive and _never_ see any errors with the
setting set to . There are no messages emitted by the kernel that there
were any system errors encountered leading one to believe that all is well, when
it isn't.
What is interesting, is that the I/O writes increase from once every 14 seconds to
once every 2-3 seconds and the FS corruption diminishes but don't disappear
if a background "dd if=/dev/zero of=/dev/null" is running.
Is this expected kernel behavior?
VMSTAT follow... when copying files from SCSI drives to IDE drive.
More info available if needed...
Thanks,
Martin
The waiting processes are kupdated and bdflush. (I have Alt-SysRq- trace of them)
VMSTAT 1 for the case w/ BIOS set to looks like (w/o dd running):
procs memoryswap io system cpu
r b w swpd free buff cache si sobibo incs us sy id
0 0 0 0 83180 1056 39800 0 0 261 3 8343 5 8 87
0 0 0 0 83176 1056 39800 0 0 0 0 11920 3 2 95
0 0 0 0 83176 1056 39800 0 0 0 0 11620 2 2 96
0 1 0 0 83012 1096 39812 0 0 329 0 196 183 3 8 89
0 1 0 0 81268 1128 41444 0 0 1021 0 309 275 3 17 80
0 1 0 0 74464 1200 47716 0 0 313127 292 264 6 25 69
2 0 0 0 67772 1276 53632 0 0 2962 0 397 245 12 25 63
2 0 0 0 64016 1324 56900 0 0 1602 0 414 155 48 27 26
1 1 0 0 53924 1372 66608 0 0 4960 0 200 165 14 40 46
1 0 0 0 42260 1448 77556 0 0 5493 0 232 210 3 35 62
0 1 0 0 30276 1480 88748 0 0 5616 0 201 124 4 34 62
2 0 0 0 22580 1496 96044 0 0 3671 2868 30796 2 33 65
0 1 0 0 12392 1528 105492 0 0 4771 4852 276 164 5 37 58
1 0 0 0 3056 1560 114232 0 0 4641 4861 328 200 2 43 54
1 1 0 0 3056 1588 114192 0 0 5011 4744 281 139 5 39 57
1 0 1 0 3056 1612 114168 0 0 5269 1728 256 115 4 35 60
0 1 1 0 3056 1680 114084 0 0 4827 0 271 193 2 33 64
1 0 1 0 3056 1708 114056 0 0 5268 0 236 106 3 38 59
2 0 1 0 3056 1748 113864 0 0 3817 3968 315 132 7 44 49
2 0 1 0 3056 1760 113604 0 0 2955 0 34863 41 50 9
1 0 1 0 3056 1788 113940 0 0 4258 0 24797 41 46 13
1 0 1 0 3056 1844 113880 0 0 4246 0 281 168 4 36 60
0 1 1 0 3064 1856 113868 0 0 2955 0 20969 3 19 78
0 1 2 0 3064 1856 113868 0 0 0 0 14927 2 3 95
0 1 2 0 3064 1856 113868 0 0 0 0 14719 2 3 95
0 1 2 0 3064 1856 113868 0 0 0 0 15218 2 3 95
0 1 2 0 3064 1856 113868 0 0 0 0 14716 2 4 94
0 1 2 0 3064 1856 113868 0 0 0 0 14716 1 4 94
0 1 1 0 3060 1856 113868 0 0 0 3613 15628 1 5 94
0 1 1
Re: [OT] Suitable Athlon Motherboard for Linux
Unfortunately, some distros will have some configurations, patches, and customizations that may cause problems with some systems. I am using an EPoX 8KTA3+ (with IDE ATA100 RAID controller) and have absolutely no problems with RedHat 6.1, or my current RedHat 7.1, and I am using the RAID controller in a non-RAID configuration. Using Mandrake for critical applications such as servers and firewalls, I have always had "strange" unexplained lock-ups, etc (that was on Mandrake 7.0). What will really matter is what hardware you're plugging into the motherboard and it's interaction with those cards. My system (which runs without any problems whatsoever): EPoX 8KTA3+ Mainboard Athlon K7 1.2GHz 512MB RAM 1 CDROM on IDE0 (standard 52x) 1 CDRW on IDE1 (Plextor Plexwriter 16/10/40A) 1 30 GB Seagate HD on IDE2 (Highpoint RAID Controller part of mainboard) 1 6GB Western Digital on IDE3 (Highpoint RAID Controller part of mainboard) GeForce2 MX (32MB RAM) Netgear FA311 NIC - Original Message - From: "Stephen M. Williams" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, July 06, 2001 10:52 PM Subject: Re: [OT] Suitable Athlon Motherboard for Linux > Seems to run fine here. I'm using a Tyan S2380 (600MHz pre-Thunderbird) > with the VIA KX-133 chipset, running Kernel 2.4.5 > > On 04 Jul 2001 19:49:50 +0100, Joseph Mathewson wrote: > > Having heard the various horror stories about the VIA PCI data corruption > > bugs, and watching one Via based machine destroy itself with a Mandrake 8.0 > > 2.4.3, I was just wondering if anyone had a suggestion for an Athlon > > motherboard that works reliably under Linux (I don't think all the issues > > have been cleared up in the kernel yet?). There must be quite a few Linux > > Athlon users out there - what boards are you using and with what success? > > > > I can't see much alternative to Via chipsets in the Ahtlon market, other > > than all-in-one-graphics-sound-network jobbies that, from previous > > experience (namely the i810), are also best avoided. > > > > Joe. > > Stephen Williams > mailto:[EMAIL PROTECTED] > > * I've tried killing time, but it keeps making a comeback. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message 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: Tulip driver doesn't work as module on 2.4.6
Frank Davis wrote: > > John, >What do the logs say? > Regards, > -Frank > -- Jul 5 23:32:48 speedy kudzu: failed Jul 5 23:32:48 speedy kudzu: Hardware configuration timed out. Jul 5 23:32:48 speedy kudzu: Run '/usr/sbin/kudzu' from the command line to re- detect. Jul 5 23:32:48 speedy sysctl: net.ipv4.ip_forward = 0 Jul 5 23:32:53 speedy lpd: lpd startup succeeded Jul 5 23:32:48 speedy sysctl: net.ipv4.conf.all.rp_filter = 1 Jul 5 23:32:48 speedy sysctl: error: 'net.ipv4.ip_always_defrag' is an unknown key Jul 5 23:32:48 speedy sysctl: error: 'kernel.sysrq' is an unknown key Jul 5 23:32:48 speedy network: Setting network parameters succeeded Jul 5 23:32:49 speedy network: Bringing up interface lo succeeded Jul 5 23:32:49 speedy network: Bringing up interface eth0 succeeded Jul 5 23:32:50 speedy portmap: portmap startup succeeded Greg Rollins wrote: > > John Kacur wrote: > > > Hi > > > > With Kernel 2.4.6, when I compile the Tulip driver as a module, I don't > > have network connectivity. I can ping myself, and netstat -rn gives the > > same table as with earlier kernels, but I can't connect to any of the > > other computers on my network. (network = 1 pentium 120, and 1 pentium > > 133 running a 2.2.16 and a 2.0.36 kernel respectively.) (the module is > > loaded correctly and I have all the correct levels of support programs > > as listed in the Changes file.) When I compile the Tulip driver directly > > into the Kernel, it works. > > > > I would be happy to provide more information to anybody who wants to try > > to figure this one out, just ask me what you need to know. > > > > Thanks > > > > John Kacur > > > > [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/ > > I haven't had this problem. I did my compile last p.m. and so far my Compaq > Deskpro is running better than ever. Which tulip based card are you > running? Mine is a Linksys 10/100. More detail please. I'm doing a modular > load also. > > Greg Rollins > [EMAIL PROTECTED] > Mine is also a Linksys 10/100 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Suitable Athlon Motherboard for Linux
Seems to run fine here. I'm using a Tyan S2380 (600MHz pre-Thunderbird) with the VIA KX-133 chipset, running Kernel 2.4.5 On 04 Jul 2001 19:49:50 +0100, Joseph Mathewson wrote: > Having heard the various horror stories about the VIA PCI data corruption > bugs, and watching one Via based machine destroy itself with a Mandrake 8.0 > 2.4.3, I was just wondering if anyone had a suggestion for an Athlon > motherboard that works reliably under Linux (I don't think all the issues > have been cleared up in the kernel yet?). There must be quite a few Linux > Athlon users out there - what boards are you using and with what success? > > I can't see much alternative to Via chipsets in the Ahtlon market, other > than all-in-one-graphics-sound-network jobbies that, from previous > experience (namely the i810), are also best avoided. > > Joe. Stephen Williams mailto:[EMAIL PROTECTED] * I've tried killing time, but it keeps making a comeback. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hi all, a strange full lock in SMP-kernel 2.4.6 and 2.4.5
I think I've seen this same problem, at least with regards to USB printing. Yesterday, I traced the problem down to a patch to usb-uhci.c in the transition from 2.4.3 to 2.4.4. The problem persists today. A work around for this problem is to use the alternate UHCI driver (uhci.o). What motherboard and chipset are you using. I use the Tyan Tiger 133 motherboard with the VIA Apollo Pro 133a chipset. Someone else who I heard from uses another VIA-based chipset (I think, he never replied to my question). Maybe this is a VIA-related problem, like the APIC problem is. (Do you use "noapic" when you boot? He and I both have SMP systems too) I posted something on the linux-usb list yesterday about this problem and with all the info I was able to track down, but I have yet to see any response. I've taken this as far as I can by myself. I don't know enough about kernel programming or about USB to check the code in usb-uhci.c, but I'm more than happy to help by providing information and/or testing potential patches/fixes. pete On Sat, 07 Jul 2001, linuxx wrote: > Well Full lock in 2.4.5 and .6 when in a SMP intel p III 500mhz when i try to print >any file in a epson 760 usb and parport > printer. > I put in antecedents . With 2.4.3 and before the printer via usb or partport print >ok . In 2.4.5-6 when i try to send > anything to /dev/usb/lp0 like cat a.txt > /dev/usb/lp0 the system fail or if i do in >lpr same . I have no problem if i use parport whit the sames kernels .I have all >right configured. With the same computer in other distribution .Same kernel = same >lock .Of course the LPRng and gcc are > all compiled in this machine and work right for months , both stables versions.I put >the only trace y can get for the lock. > I hope help something for any other thing i not subscribed to kernel list so i like >to know any answer you can give. THANKS > > CPU:0 > EIP:0010:[] > EFLAGS: 0086 > eax: cd747600 ebx: cd1d42a0 ecx: 0001 edx: cd747600 > esi: cd1d41fc edi: ebp: 0004 esp: cd077f34 > ds: 0018 es: 0018 ss:0018 > Process cat (pid: 378, stackpage=cd077000) > Stack: 017a 0005 0206 cd1d41a0 cd8f >0004 d0837aac cd1d41fc d084e411 cd1d41fc cdec8c60 ffea > 0004 c013a1c6 cdec8c60 0804c860 0004 cdec8c80 0025 > > Call Trace: [<013a1c6>] [] > Code: 80 7b 24 00 f3 90 7e f8 e9 e0 d0 ff ff 80 bf 80 00 00 00 00 > console shuts up ... > > +++ killed by SIGSEGV +++ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] PPC interrupt mapping fix
Linus,
The patch below fixes the interrupt assignments on PPC machines that
use Open Firmware, in the case where we have devices behind a PCI-PCI
bridge and multiple PCI host bridges. The patch is moderately large
because I rewrote the procedure that parsed the open firmware
interrupt tree. The previous routine was monolithic and almost
unreadable - I wrote a new version which uses several subroutines and
should be much more readable. There are also some fixes to allow us
to use the interrupt tree on powermacs when booted with BootX, which
we couldn't do previously.
Please apply to your tree.
Paul.
diff -urN linux/arch/ppc/kernel/prom.c pmac/arch/ppc/kernel/prom.c
--- linux/arch/ppc/kernel/prom.cWed Jul 4 14:33:18 2001
+++ pmac/arch/ppc/kernel/prom.c Wed Jul 4 22:53:29 2001
@@ -116,8 +116,11 @@
unsigned int rtas_size;
unsigned int old_rtas;
-/* Set for a newworld machine */
+/* Set for a newworld or CHRP machine */
int use_of_interrupt_tree;
+struct device_node *dflt_interrupt_controller;
+int num_interrupt_controllers;
+
int pmac_newworld;
static struct device_node *allnodes;
@@ -1153,7 +1156,19 @@
*prev_propp = PTRUNRELOC(pp);
prev_propp = >next;
}
- *prev_propp = 0;
+ if (np->node != NULL) {
+ /* Add a "linux,phandle" property" */
+ pp = (struct property *) mem_start;
+ *prev_propp = PTRUNRELOC(pp);
+ prev_propp = >next;
+ namep = (char *) (pp + 1);
+ pp->name = PTRUNRELOC(namep);
+ strcpy(namep, RELOC("linux,phandle"));
+ mem_start = ALIGN((unsigned long)namep + strlen(namep) + 1);
+ pp->value = (unsigned char *) PTRUNRELOC(>node);
+ pp->length = sizeof(np->node);
+ }
+ *prev_propp = NULL;
/* get the node's full name */
l = (int) call_prom(RELOC("package-to-path"), 3, 1, node,
@@ -1186,19 +1201,46 @@
finish_device_tree(void)
{
unsigned long mem = (unsigned long) klimit;
+ struct device_node *np;
- /* All newworld machines now use the interrupt tree */
- struct device_node *np = allnodes;
-
- while(np && (_machine == _MACH_Pmac)) {
+ /* All newworld pmac machines and CHRPs now use the interrupt tree */
+ for (np = allnodes; np != NULL; np = np->allnext) {
if (get_property(np, "interrupt-parent", 0)) {
- pmac_newworld = 1;
+ use_of_interrupt_tree = 1;
break;
}
- np = np->allnext;
}
- if ((_machine == _MACH_chrp) || (boot_infos == 0 && pmac_newworld))
- use_of_interrupt_tree = 1;
+ if (_machine == _MACH_Pmac && use_of_interrupt_tree)
+ pmac_newworld = 1;
+
+#ifdef CONFIG_BOOTX_TEXT
+ if (boot_infos && pmac_newworld) {
+ prom_print("WARNING ! BootX/miBoot booting is not supported on this
+machine\n");
+ prom_print(" You should use an Open Firmware bootloader\n");
+ }
+#endif /* CONFIG_BOOTX_TEXT */
+
+ if (use_of_interrupt_tree) {
+ /*
+* We want to find out here how many interrupt-controller
+* nodes there are, and if we are booted from BootX,
+* we need a pointer to the first (and hopefully only)
+* such node. But we can't use find_devices here since
+* np->name has not been set yet. -- paulus
+*/
+ int n = 0;
+ char *name;
+
+ for (np = allnodes; np != NULL; np = np->allnext) {
+ if ((name = get_property(np, "name", NULL)) == NULL
+ || strcmp(name, "interrupt-controller") != 0)
+ continue;
+ if (n == 0)
+ dflt_interrupt_controller = np;
+ ++n;
+ }
+ num_interrupt_controllers = n;
+ }
mem = finish_node(allnodes, mem, NULL, 1, 1);
dev_tree_size = mem - (unsigned long) allnodes;
@@ -1240,9 +1282,8 @@
if (ifunc != NULL) {
mem_start = ifunc(np, mem_start, naddrc, nsizec);
}
- if (use_of_interrupt_tree) {
+ if (use_of_interrupt_tree)
mem_start = finish_node_interrupts(np, mem_start);
- }
/* Look for #address-cells and #size-cells properties. */
ip = (int *) get_property(np, "#address-cells", 0);
@@ -1298,141 +1339,210 @@
return mem_start;
}
-/* This routine walks the interrupt tree for a given device node and gather
- * all necessary informations according to the draft interrupt mapping
- * for CHRP. The current version was only tested on Apple "Core99" machines
- * and may not handle cascaded controllers correctly.
+/*
+ * Find the interrupt parent of a
Re: Tulip driver doesn't work as module on 2.4.6
John Kacur wrote: > Hi > > With Kernel 2.4.6, when I compile the Tulip driver as a module, I don't > have network connectivity. I can ping myself, and netstat -rn gives the > same table as with earlier kernels, but I can't connect to any of the > other computers on my network. (network = 1 pentium 120, and 1 pentium > 133 running a 2.2.16 and a 2.0.36 kernel respectively.) (the module is > loaded correctly and I have all the correct levels of support programs > as listed in the Changes file.) When I compile the Tulip driver directly > into the Kernel, it works. > > I would be happy to provide more information to anybody who wants to try > to figure this one out, just ask me what you need to know. > > Thanks > > John Kacur > > [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/ I haven't had this problem. I did my compile last p.m. and so far my Compaq Deskpro is running better than ever. Which tulip based card are you running? Mine is a Linksys 10/100. More detail please. I'm doing a modular load also. Greg Rollins [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: [RFC] __initstr & __exitstr
Em Fri, Jul 06, 2001 at 10:05:14PM -0500, Philipp Rumpf escreveu:
> On Fri, Jul 06, 2001 at 11:17:44PM -0300, Arnaldo Carvalho de Melo wrote:
> > Hi,
> >
> > Please comment on this approach to move strings in __init functions
> > from .rodata to .data.init so that it get discarded after initialization,
> > like the variables marked as __initdata and the functions marked as __init,
> > as well as move strings in __exit marked functions to .data.exit, that will
> > be discarded and not even get into the generated kernel image.
> >
> > Please note that if possible the best approach was for gcc to move
> > those strings automatically if the function was marked with modified
> > __init/__exit macros, but we have to keep in mind that some of the strings
> > in those functions can not be discarded because they keep being referenced
> > by say register_chrdev and others, unlike, for example, proc functions and
> > others that copy the string passed to some malloc'ed data structure, so we
> > have to be selective marking exactly the ones that can indeed be discarded.
>
> .. or fix all registration functions to use a private copy of the string,
> which would avoid some common oopses.
yes, that would be nice, if allowed I can put my janitor hat and do that :)
> > I've also implemented helper functions for printk thats the most
> > common case, and leaved the other common case, panic, using
> > __initstr/__exitstr explicitely, so that people can comment on what is
> > better.
>
> > #define init_printk(fmt,arg...) printk(__initstr(fmt) , ##arg)
>
> I dislike init_printk; it combines variadic functions/macros with
> assumptions about how the first argument is specified (i.e. as a string
> constant), so it's potentially very confusing.
>
> Also, printk is used for debugging, and accidentally using init_printk
> instead of printk would result in no messages being printed at all if
> the driver is compiled into the kernel (while everything would work
> fine if the driver is compiled as a module, where init_printk and printk
> are identical). I think this would be very annoying to track down for
> less experienced kernel hackers.
that's why I've didn't coded a init_panic :) ok, I can change this if the
rest of the patch is considered ok
> > #define __initstr(s)({ static char __tmp_init_str[] __initdata=s;
> > __tmp_init_str;})
>
> I think this would fail if used in structure initialisations ?
yes, this fails in such cases, any ideas on another approach that works in
this case as well in the other cases covered by the patch?
Also please note that strings in __initdata marked structs with just 'char
*' instances are going to .rodata and not getting discarded, thats why I've
changed some to char[SOME_MAX_STRING_SIZE], so that it gets moved to
.data.init, crude, but works, I'm interested in another approach for this
case as well.
Thanks for the comments.
- Arnaldo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] __initstr & __exitstr
On Fri, Jul 06, 2001 at 11:17:44PM -0300, Arnaldo Carvalho de Melo wrote:
> Hi,
>
> Please comment on this approach to move strings in __init functions
> from .rodata to .data.init so that it get discarded after initialization,
> like the variables marked as __initdata and the functions marked as __init,
> as well as move strings in __exit marked functions to .data.exit, that will
> be discarded and not even get into the generated kernel image.
>
> Please note that if possible the best approach was for gcc to move
> those strings automatically if the function was marked with modified
> __init/__exit macros, but we have to keep in mind that some of the strings
> in those functions can not be discarded because they keep being referenced
> by say register_chrdev and others, unlike, for example, proc functions and
> others that copy the string passed to some malloc'ed data structure, so we
> have to be selective marking exactly the ones that can indeed be discarded.
.. or fix all registration functions to use a private copy of the string,
which would avoid some common oopses.
> I've also implemented helper functions for printk thats the most
> common case, and leaved the other common case, panic, using
> __initstr/__exitstr explicitely, so that people can comment on what is
> better.
> #define init_printk(fmt,arg...) printk(__initstr(fmt) , ##arg)
I dislike init_printk; it combines variadic functions/macros with
assumptions about how the first argument is specified (i.e. as a string
constant), so it's potentially very confusing.
Also, printk is used for debugging, and accidentally using init_printk
instead of printk would result in no messages being printed at all if
the driver is compiled into the kernel (while everything would work
fine if the driver is compiled as a module, where init_printk and printk
are identical). I think this would be very annoying to track down for
less experienced kernel hackers.
> #define __initstr(s)({ static char __tmp_init_str[] __initdata=s;
> __tmp_init_str;})
I think this would fail if used in structure initialisations ?
Philipp Rumpf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] fix drivers/usb/scanner.c ioctl return
The following patch corrects the return value from the ioctl function in the USB scanner code, in the case where the ioctl is unrecognized. Linus, please apply. Paul. diff -urN linux/drivers/usb/scanner.c pmac/drivers/usb/scanner.c --- linux/drivers/usb/scanner.c Sat Apr 28 23:02:49 2001 +++ pmac/drivers/usb/scanner.c Thu Jun 28 17:28:25 2001 @@ -909,7 +909,7 @@ return result; } default: - return -ENOIOCTLCMD; + return -ENOTTY; } return 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/
drivers/ide/sl82c105.c
I am wondering who maintains drivers/ide/sl82c105.c, and who sent in
the recent changes to it. We now have, at around line 278, this code:
unsigned int pci_init_sl82c105(struct pci_dev *dev, const char *msg)
{
return ide_special_settings(dev, msg);
}
The call to ide_special_settings gives a link error because
ide_special_settings is not exported from drivers/ide/ide-pci.c.
I can't see what the point of calling it is anyway, even if it were
exported, since ide_special_settings consists of a switch statement on
the device ID and none of the cases will match.
Paul (who uses sl82c105.c on his longtrail PPC CHRP box).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] fix compile error in usb-ohci.c
The following patch fixes a trivial error in drivers/usb/usb-ohci.c,
where a missing argument to ohci_pci_suspend will cause a compile
error if you have powerbook support enabled.
Linus, please apply.
Paul.
diff -urN linux/drivers/usb/usb-ohci.c pmac/drivers/usb/usb-ohci.c
--- linux/drivers/usb/usb-ohci.cWed Jul 4 14:33:36 2001
+++ pmac/drivers/usb/usb-ohci.c Fri Jul 6 16:20:58 2001
@@ -2749,7 +2749,7 @@
switch (when) {
case PBOOK_SLEEP_NOW:
- ohci_pci_suspend (ohci->ohci_dev);
+ ohci_pci_suspend (ohci->ohci_dev, 3);
break;
case PBOOK_WAKE:
ohci_pci_resume (ohci->ohci_dev);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC] __initstr & __exitstr
Hi,
Please comment on this approach to move strings in __init functions
from .rodata to .data.init so that it get discarded after initialization,
like the variables marked as __initdata and the functions marked as __init,
as well as move strings in __exit marked functions to .data.exit, that will
be discarded and not even get into the generated kernel image.
Please note that if possible the best approach was for gcc to move
those strings automatically if the function was marked with modified
__init/__exit macros, but we have to keep in mind that some of the strings
in those functions can not be discarded because they keep being referenced
by say register_chrdev and others, unlike, for example, proc functions and
others that copy the string passed to some malloc'ed data structure, so we
have to be selective marking exactly the ones that can indeed be discarded.
I've also implemented helper functions for printk thats the most
common case, and leaved the other common case, panic, using
__initstr/__exitstr explicitely, so that people can comment on what is
better.
Here is the basic implementation in include/linux/init.h:
#define __initstr(s)({ static char __tmp_init_str[] __initdata=s;
__tmp_init_str;})
#define __exitstr(s)({ static char __tmp_exit_str[] __exitdata=s;
__tmp_exit_str;})
#define init_printk(fmt,arg...) printk(__initstr(fmt) , ##arg)
#define exit_printk(fmt,arg...) printk(__exitstr(fmt) , ##arg)
For modules its a no op, as modules doesn't get rid of code/data
marked as __init{data}, please correct me if I'm wrong as I didn't checked
that in detail, but from first quick analysis it doesn't move it to some
different .data/.text section, so I assume it doesn't discards it after
initialization.
For my config, compiling everything statically, with a pristine
2.4.6-ac1 kernel I get 172 KB freed after init, with this patch we save 16
KB more.
I've put the patch at:
http://bazar.conectiva.com.br/~acme/patches/wip/__initstr.patch.4
And yes, its intrusive, but it serves, IMHO, as an experiment to
see how much can be saved with this.
Please advise/comment.
- Arnaldo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 #2] OOM kill trigger
Rik van Riel wrote: > + cache_mem = atomic_read(_cache_size); > + cache_mem += atomic_read(_pages); > + cache_mem -= swapper_space.nrpages; > + limit = (page_cache.min_percent + buffer_mem.min_percent); Don't you need extra protection around swapper_space.nrpages? A barrier right above it? -- Jeff Garzik | A recent study has shown that too much soup Building 1024| can cause malaise in laboratory mice. 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/
[PATCH] fix compile error in imsttfb.c
As it currently stands, drivers/video/imsttfb.c will give a compile
error if FBCON_HAS_CFB32 is defined. This patch fixes that.
There used to be a declaration of `i' which was only used if
FBCON_HAS_CFB32 was defined. I suspect that somebody was compiling
without FBCON_HAS_CFB32 and saw an unused variable warning from gcc
and decided to take out the declaration. This patch will avoid that
warning.
Linus, please apply.
Paul.
diff -urN linux/drivers/video/imsttfb.c linuxppc_2_4/drivers/video/imsttfb.c
--- linux/drivers/video/imsttfb.c Thu Jul 5 14:46:16 2001
+++ linuxppc_2_4/drivers/video/imsttfb.cThu Jul 5 10:58:09 2001
@@ -1278,10 +1278,11 @@
break;
#endif
#ifdef FBCON_HAS_CFB32
- case 32:
- i = (regno << 8) | regno;
+ case 32: {
+ int i = (regno << 8) | regno;
p->fbcon_cmap.cfb32[regno] = (i << 16) | i;
break;
+ }
#endif
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Tulip driver doesn't work as module on 2.4.6
Hi With Kernel 2.4.6, when I compile the Tulip driver as a module, I don't have network connectivity. I can ping myself, and netstat -rn gives the same table as with earlier kernels, but I can't connect to any of the other computers on my network. (network = 1 pentium 120, and 1 pentium 133 running a 2.2.16 and a 2.0.36 kernel respectively.) (the module is loaded correctly and I have all the correct levels of support programs as listed in the Changes file.) When I compile the Tulip driver directly into the Kernel, it works. I would be happy to provide more information to anybody who wants to try to figure this one out, just ask me what you need to know. Thanks John Kacur [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: supermount
I gree with Stevie Kieu and Sam Halliday -- Best regards, Dj_RzulF - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] eepro100 PCI/PM fixes
Linus,
Could you apply the following patch, please?
Andrey
- Forwarded message from Kai Germaschewski <[EMAIL PROTECTED]> -
Delivered-To: [EMAIL PROTECTED]
Date: Fri, 6 Jul 2001 22:51:02 +0200 (CEST)
From: Kai Germaschewski <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: [PATCH] eepro100 PCI/PM fixes
Hi!
Appened patch against 2.4.7-pre3 fixes a couple of issues in the eepro100
driver. I realize some of the changes may be not appropriate due to
compatibility concerns or whatever.
o call pci_enable_device before accessing resources/irqs.
pci_enable_device needs to be called, because it may change/assign the
IRQ / resources (not yet).
o call pci_disable_device at appropriate places. Not urgently needed but
cleaner anyway.
o pci_set_power_state is provided by include/linux/pci.h even if
CONFIG_PM is not set
o .acpi_pwr was never really used
o don't do the acpi_idle_state thing. Drivers shouldn't need to care about
this level of things. After an open/close cycle, the chip will be placed
in D2. So it's just consistent to do so before the first open as well.
--Kai
diff -urN linux-2.4.7-pre3.1/drivers/net/eepro100.c
linux-2.4.7-pre3.work/drivers/net/eepro100.c
--- linux-2.4.7-pre3.1/drivers/net/eepro100.c Wed Jul 4 12:37:13 2001
+++ linux-2.4.7-pre3.work/drivers/net/eepro100.cFri Jul 6 22:41:26 2001
@@ -139,16 +139,6 @@
#define RUN_AT(x) (jiffies + (x))
-/* ACPI power states don't universally work (yet) */
-#ifndef CONFIG_PM
-#undef pci_set_power_state
-#define pci_set_power_state null_set_power_state
-static inline int null_set_power_state(struct pci_dev *dev, int state)
-{
- return 0;
-}
-#endif /* CONFIG_PM */
-
#define netdevice_start(dev)
#define netdevice_stop(dev)
#define netif_set_tx_timeout(dev, tf, tm) \
@@ -165,7 +155,7 @@
#endif
-int speedo_debug = 1;
+static int speedo_debug = 1;
/*
Theory of Operation
@@ -281,7 +271,7 @@
*/
-static int speedo_found1(struct pci_dev *pdev, long ioaddr, int fnd_cnt, int
acpi_idle_state);
+static int speedo_found1(struct pci_dev *pdev, long ioaddr, int fnd_cnt);
enum pci_flags_bit {
PCI_USES_IO=1, PCI_USES_MEM=2, PCI_USES_MASTER=4,
@@ -480,7 +470,6 @@
struct speedo_mc_block *mc_setup_head;/* Multicast setup frame list head. */
struct speedo_mc_block *mc_setup_tail;/* Multicast setup frame list tail. */
long in_interrupt; /* Word-aligned
dev->interrupt */
- unsigned char acpi_pwr;
signed char rx_mode;/* Current
PROMISC/ALLMULTI setting. */
unsigned int tx_full:1; /* The Tx queue is full. */
unsigned int full_duplex:1; /* Full-duplex operation
requested. */
@@ -559,17 +548,21 @@
{
unsigned long ioaddr;
int irq;
- int acpi_idle_state = 0, pm;
static int cards_found /* = 0 */;
static int did_version /* = 0 */; /* Already printed version
info. */
if (speedo_debug > 0 && did_version++ == 0)
printk(version);
+ if (pci_enable_device(pdev))
+ goto err_out_none;
+
+ pci_set_master(pdev);
+
if (!request_region(pci_resource_start(pdev, 1),
pci_resource_len(pdev, 1), "eepro100")) {
printk (KERN_ERR "eepro100: cannot reserve I/O ports\n");
- goto err_out_none;
+ goto err_out_disable;
}
if (!request_mem_region(pci_resource_start(pdev, 0),
pci_resource_len(pdev, 0), "eepro100")) {
@@ -596,20 +589,7 @@
pci_resource_start(pdev, 0), irq);
#endif
- /* save power state b4 pci_enable_device overwrites it */
- pm = pci_find_capability(pdev, PCI_CAP_ID_PM);
- if (pm) {
- u16 pwr_command;
- pci_read_config_word(pdev, pm + PCI_PM_CTRL, _command);
- acpi_idle_state = pwr_command & PCI_PM_CTRL_STATE_MASK;
- }
-
- if (pci_enable_device(pdev))
- goto err_out_free_mmio_region;
-
- pci_set_master(pdev);
-
- if (speedo_found1(pdev, ioaddr, cards_found, acpi_idle_state) == 0)
+ if (speedo_found1(pdev, ioaddr, cards_found) == 0)
cards_found++;
else
goto err_out_iounmap;
@@ -624,12 +604,14 @@
release_mem_region(pci_resource_start(pdev, 0), pci_resource_len(pdev, 0));
err_out_free_pio_region:
release_region(pci_resource_start(pdev, 1), pci_resource_len(pdev, 1));
+err_out_disable:
+ pci_disable_device(pdev);
err_out_none:
return -ENODEV;
}
static int speedo_found1(struct pci_dev *pdev,
- long ioaddr, int card_idx, int acpi_idle_state)
+long ioaddr, int card_idx)
{
struct net_device *dev;
struct
RE: Trouble Booting Linux PPC On Mac G4 2000
Tim McDaniel writes: > We are having a great degree of difficulty getting Linux PPC2 > running on a Mac G4 466 tower with 128MB of memory, One 30MB HD and one > CR RW. This is not a NuBus based system. To the best of our knowledge we > have followed the user manual to the tee, and even tried forcing video > settings at the Xboot screen. One possible problem is that many Apple monitors only work at a fixed horizontal frequency - the Apple Studio 17 monitor (with the transparent case) that I use with my G4 cube is like that, it will only operate at horizontal scan rates between 79 and 82 kHz. If the kernel video driver chooses a video mode with a scan rate outside that range the screen goes black. So I have to put video=aty128fb:vmode:20 on the kernel command line to avoid that. (It would be nice if the kernel driver did DDC but it doesn't.) Other than that, you might get more useful suggestions if you ask on the [EMAIL PROTECTED] mailing list. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Hi all, a strange full lock in SMP-kernel 2.4.6 and 2.4.5
Well Full lock in 2.4.5 and .6 when in a SMP intel p III 500mhz when i try to print
any file in a epson 760 usb and parport
printer.
I put in antecedents . With 2.4.3 and before the printer via usb or partport print ok
. In 2.4.5-6 when i try to send
anything to /dev/usb/lp0 like cat a.txt > /dev/usb/lp0 the system fail or if i do in
lpr same . I have no problem if i use parport whit the sames kernels .I have all right
configured. With the same computer in other distribution .Same kernel = same lock .Of
course the LPRng and gcc are
all compiled in this machine and work right for months , both stables versions.I put
the only trace y can get for the lock.
I hope help something for any other thing i not subscribed to kernel list so i like to
know any answer you can give. THANKS
CPU:0
EIP:0010:[]
EFLAGS: 0086
eax: cd747600 ebx: cd1d42a0 ecx: 0001 edx: cd747600
esi: cd1d41fc edi: ebp: 0004 esp: cd077f34
ds: 0018 es: 0018 ss:0018
Process cat (pid: 378, stackpage=cd077000)
Stack: 017a 0005 0206 cd1d41a0 cd8f
0004 d0837aac cd1d41fc d084e411 cd1d41fc cdec8c60 ffea
0004 c013a1c6 cdec8c60 0804c860 0004 cdec8c80 0025
Call Trace: [<013a1c6>] []
Code: 80 7b 24 00 f3 90 7e f8 e9 e0 d0 ff ff 80 bf 80 00 00 00 00
console shuts up ...
+++ killed by SIGSEGV +++
--
Lee y algo aprenderás:
#--
I used to think romantic love was a neurosis shared by two, a supreme
foolishness. I no longer thought that. There's nothing foolish in
loving anyone. Thinking you'll be loved in return is what's foolish.
-- Rita Mae Brown
#--
Luis Toro Teijeiro THANKS FOR YOUR TIME.
()
(o_|||
AÑO 3021 del //\ | demoniaco.
<<-V_/_|
ICQ : 42466380
pasate por http://www.gulic.org y veras Canarias y los linuxeros
http://jaya.dyndns.org --pagina personal
Firma gnupg disponible en https://jaya.dyndns.org/linux/GNUPG/
GnupgFingerprint: 8F06 3E9A F610 89BF 0B09 3DEB 0C7E 9AE1 6CE0 B251
Windows Where do you want to go today?
MacOS Where do you want to be tomorrow?
Linux Are you coming, or what?
PGP signature
Re: 2.4.6-ac1 will not build, 2.4.6 ok
On Friday 06 July 2001 16:35, Tom Diehl wrote:
> Hi all,
> This is my first bug report so please go easy on me if I screw it up.
> The kernel 2.4.6-ac1
> The build machine AMD k6-2-350 with 128Megs of memory
> I get the following errors when I try to build ac1. It builds ok when
> just building 2.4.6 with the same config file run through make old_config,
> so I guess this is some kind of problem with ac1.
I posted a patch for this a few hours after 2.4.6-ac1 became available, but
there have been problems with lkml archive servers in the interim, so here
is my patch again. If you look in drivers/parport/parport_pc.c, you'll see that
the new code is bracketed by:
#if defined (CONFIG_PNPBIOS) || defined (CONFIG_PNPBIOS_MODULE)
new stuff for 2.4.6-ac1
#endif
Steven
--- linux-2.4.6-ac1/drivers/parport/parport_pc.c.original    Wed Jul  4 15:22:28
2001
+++ linux/drivers/parport/parport_pc.c  Wed Jul  4 15:26:03 2001
@@Â -2828,12 +2828,14 @@
    detect_and_report_smsc ();
 #endif
Â
+#if defined (CONFIG_PNPBIOS) || defined (CONFIG_PNPBIOS_MODULE)
    dev=NULL;
    while ((dev=pnpbios_find_device("PNP0400",dev)))
        count+=init_pnp040x(dev);
    dev=NULL;
     while ((dev=pnpbios_find_device("PNP0401",dev)))
         count+=init_pnp040x(dev);
+#endif
Â
    /* Onboard SuperIO chipsets that show themselves on the PCI bus. */
    count += parport_pc_init_superio (autoirq, autodma);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Athlon oops traced to CONFIG_MK7 code in arch/i386/lib/mmx.c
Athlon oops saga continues - I consistently get Athlon kernels oopsing during the boot up process either in rc.sysinit or loading of usb modules (this is a RedHat system 7.1). These kernels can boot to a shell init=/bin/sh but once I try to do stuff like inserting modules they oops left, right, and centre. System: Athlon 1.2GHz VIA KT 133A Kernel: 2.4.5 and -ac, 2.4.6 and -ac Compiler: gcc 2.96-RH/3.00/3.01 binutils 2.10.90/2.11.2/2.11.90 I have narrowed a(the?) problem down to the CONFIG_MK7 specific code in arch/i386/lib/mmx.c. If I disable CONFIG_MK7 in that one file with the rest of the kernel untouched and compiled with CONFIG_MK7 and -march=athlon then my kernel boots sucessfully and manages to get into multi-user mode. With a few minutes of testing and X everything works fine. I'm interested if there is an explanation of the MK7 specific code in mmx.c and whether that could really be the source of the problem. I would like to get to the bottom of this. FWIW - the RedHat 7.1 stock 2.4.2 athlon kernel boots successfully without oopsen. Thanks! Richard Chan <[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: natsemi.c failure in 2.4.6
Hi, On Sat, Jul 07, 2001 at 12:32:17AM +0200, Manfred Spraul wrote: > Perhaps powermanagement causes your receive problems? You wrote you have > a FA312. I've tested my FA311 (without mii-diag) and I didn't have any > problems with transmit or receive. Found out what was wrong. It was hardware-related after all. Sorry for the confusion. Turns out my cat chewed on my cables -- replacing them fixed it. Thanks for the help! -- DN 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/
Test case for kernel crash
I am able to crash 2.4.3 kernel on a dual Pentium 500 with 256 MB RAM and no
swap space with the program below. to compile, gcc -o oom oom.c -lpthread
Found out that my magic SysRq for some reason was not working :( so I could
not get much detail - will fix the magic and report more when it becomes
available. I have observed three types of behavior:
* once the program locked everything up ( test run from X), the machine did
not even ping. However, after some time ( about 5 minutes), the machine
became functional again
* another time, there was a complete lockup ( again in X), I waited 10
minutes, nothing happened, so I just rebooted
* then I tried the test after a clean boot - this time no X, just plain
consoles - after the run I actually got the shell back, could not type
anything. I could switch between virtual consoles, type my username at the
login prompt, but would never get the password prompt. The machine pinged,
and I could even connect to ports that had services, but got no response
after a successfull connect. My explanation is that the kernel ran out of
memory, but could not clean up.
The only relevant thing I could find in syslog is messages like this:
Jul 6 17:33:31 mysql kernel: Out of Memory: Killed process 25500 (oom).
Jul 6 17:33:35 mysql last message repeated 84 times
Jul 6 17:33:35 mysql kernel: Out of Memory: Killed process 25501 (oom).
Jul 6 17:33:35 mysql last message repeated 5 times
Jul 6 17:33:35 mysql kernel: Out of Memory: Killed process 25502 (oom).
Jul 6 17:33:35 mysql last message repeated 263 times
And last but not least - the whole reason for writing the program below was
to create a simple test case and isolate the problem in a real life threaded
application that left some unkillable ( even with -9 ) processes after
running out of memory and getting killed itself. So I suspect I have
accomplished my goal of creating unkillable process, which is what,
apparently, makes it so difficult for the kernel to recover from the stress.
Note that I had to get the process stuck in I/O to cause the problem -
without the I/O the kernel kills all the bad guys and recovers gracefully.
So let's hope this is enough info to track down the bug - if not let me know
what else is needed.
cut--
#include
#include
#include
#include
#define LEAK_BLOCK (1024*1024)
#define MB (1024*1024)
#define NUM_THREADS 64
int pipe_fd[2];
void* run_thread(void* arg)
{
unsigned long total = 0;
char buf[3];
for (;;)
{
char* p, *p_end;
if(!(p=malloc(LEAK_BLOCK)))
{
fprintf(stderr, "malloc() failed\n");
exit(1);
}
p_end = p + LEAK_BLOCK;
while(p < p_end)
*p++ = 0;
total += LEAK_BLOCK;
printf("Allocated %d MB\n", total/MB);
fflush(stdout);
read(pipe_fd[0], buf, 3);
}
return 0;
}
int main()
{
pthread_t th[NUM_THREADS];
int i;
if(pipe(pipe_fd) == -1)
{
fprintf(stderr, "Could not create pipe\n");
exit(1);
}
for(i = 0; i < NUM_THREADS; i++)
if(pthread_create(th + i, 0, run_thread, 0))
{
fprintf(stderr, "Could not create thread\n");
exit(1);
}
while(1)
{
write(pipe_fd[1], "foo", 3);
}
for(i = 0; i < NUM_THREADS; i++)
if(pthread_join(th[i], 0))
{
fprintf(stderr, "Error in pthread_join\n");
exit(1);
}
return 0;
}
-cut
--
MySQL Development Team
For technical support contracts, visit https://order.mysql.com/
__ ___ ___ __
/ |/ /_ __/ __/ __ \/ / Sasha Pachev <[EMAIL PROTECTED]>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/
/_/ /_/\_, /___/\___\_\___/ Provo, Utah, USA
<___/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Why Plan 9 C compilers don't have asm("")
Followup to: <[EMAIL PROTECTED]> By author:"David S. Miller" <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Rick Hohensee writes: > > Forth chips aren't modern in the true-multi-user sense, but if an > > individual were to design such a beast they could get several of them, > > hundreds maybe, on FPGAs available now. Such things are coming, because a > > Forth chip IS something an individual can design. > > And I suppose this zero-cost call is also handling things like keeping > an N stage deep pipeline full during this call right? > Believe it or not, that's actually a fairly simple part of the whole machinery. All you need for that is to maintain a call/return stack in the front end of the pipe. That way, a return that is indeed a return can be speculated properly; obviously, if the speculation doesn't work out when you get the return address in the execution stage you suffer a branch mispredict penalty. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
memory allocation mystery
Hello,
I have been investigating kernel behavior ( I am running 2.4.3) in out of
memory conditions with swap completely disabled and discovered a rather
interesting behavior. If you run the following code:
#include
#include
#define LEAK_BLOCK (1024*1024)
#define MB (1024*1024)
int main()
{
unsigned long total = 0;
for (;;)
{
char* p, *p_end;
if(!(p=malloc(LEAK_BLOCK)))
{
fprintf(stderr, "malloc() failed\n");
exit(1);
}
p_end = p + LEAK_BLOCK;
while(p < p_end)
*p++ = 0;
total += LEAK_BLOCK;
printf("Allocated %d MB\n", total/MB);
}
return 0;
}
the process eventually gets killed by the kernel, rather than getting an
error from malloc() as you would logically expect
I have straced the process and see just a bunch of old_mmap() calls like this:
old_mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0)
= 0x46b6a000
( in addition to writes to stdout, of course). So it looks like old_mmap()
never returns an error.
Can somebody explain this behavior? To me it looks like a bug...
--
MySQL Development Team
For technical support contracts, visit https://order.mysql.com/
__ ___ ___ __
/ |/ /_ __/ __/ __ \/ / Sasha Pachev <[EMAIL PROTECTED]>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/
/_/ /_/\_, /___/\___\_\___/ Provo, Utah, USA
<___/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.6 APM suspend kills Dell inspiron 3500 sound card, but revives network card.
My devices on my laptop work very strangely with kernel 2.4.6. -- Sound problems: The sound card on my laptop (Dell Inspiron 3500) works fine when the system first boots up, but stops working with the first suspend. Any attempt to write sound to it after that blocks indefinitely. I don't even get console beeps until I reboot. That's under kde with their not-esd daemon (I.E. using noatun). If I do the same from the console it still plays fine before the suspend (using mpg123), and afterwords plays short samples in a loop with "DMA timeout" error messages to the console. -- Network problems. I have 3 pcmcia network cards (10baseT xircomm, 100baseT cardbus thing that isn't with me right now, and a wireless card.) The two 10baseT (pcmica) ones have about the same behavior, the 100baseT (cardbus?) one's a little different. Under previous kernels (the mutuant red hat 7.1 2.4.2), the pcmcia network card would work fine on boot but die when the system suspends. (I didn't mind because I could pop it out and put it back in and it would work again.) Now with 2.4.6 it's exactly the OPPOSITE behavior: the network card doesn't work at all until I suspend and resume, but when the system comes back up after a suspend the card works fine. Before the suspend, popping it out and putting it back in accomplish nothing. Afterwards popping out and putting in work great, re-runs dhcpcd and everything. Back under red hat's 2.4.2, putting the cardbus card in, suspending, resuming, and popping the card out produced a kernel panic. I haven't tried with 2.4.6 (don't have the card with me), but I can try to reproduce this under 2.4.6 if it sounds interesting to anybody... -- Fun little detail: The two cardbus bridges and the sound card are all on IRQ 11, it seems. /proc/pci attached. Rob (P.S. I take it the XFree86 hangs are an XFree86 problem, not kernel? Rat pointer still moves, drive still chugs a bit in the background, so the kernel seems sort of still there... Can't get out of the frozen gui though, no ctrl-alt-F1, no ctrl-alt-backspace... Oh well.) PCI devices found: Bus 0, device 0, function 0: Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 2). Master Capable. Latency=64. Prefetchable 32 bit memory at 0xe000 [0xe3ff]. Bus 0, device 1, function 0: PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 2). Master Capable. Latency=128. Min Gnt=140. Bus 0, device 4, function 0: CardBus bridge: Texas Instruments PCI1220 (rev 2). IRQ 11. Master Capable. Latency=168. Min Gnt=192.Max Lat=5. Non-prefetchable 32 bit memory at 0x1000 [0x1fff]. Bus 0, device 4, function 1: CardBus bridge: Texas Instruments PCI1220 (#2) (rev 2). IRQ 11. Master Capable. Latency=168. Min Gnt=192.Max Lat=5. Non-prefetchable 32 bit memory at 0x10001000 [0x10001fff]. Bus 0, device 7, function 0: Bridge: Intel Corporation 82371AB PIIX4 ISA (rev 2). Bus 0, device 7, function 1: IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 1). Master Capable. Latency=64. I/O at 0xfcd0 [0xfcdf]. Bus 0, device 7, function 2: USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 1). IRQ 10. Master Capable. Latency=64. I/O at 0xfce0 [0xfcff]. Bus 0, device 7, function 3: Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 2). IRQ 9. Bus 1, device 0, function 0: VGA compatible controller: Neomagic Corporation [MagicMedia 256AV] (rev 18). Master Capable. Latency=128. Min Gnt=16.Max Lat=255. Prefetchable 32 bit memory at 0xfd00 [0xfdff]. Non-prefetchable 32 bit memory at 0xfe80 [0xfebf]. Non-prefetchable 32 bit memory at 0xfec0 [0xfecf]. Bus 1, device 0, function 1: Multimedia audio controller: Neomagic Corporation [MagicMedia 256AV Audio] (rev 18). IRQ 11. Prefetchable 32 bit memory at 0xfe00 [0xfe3f]. Non-prefetchable 32 bit memory at 0xfe70 [0xfe7f]. xirc2ps_cs 11808 1 ad1848 17456 1 sound 57728 1 [ad1848]
2.4.6-ac1 will not build, 2.4.6 ok
Hi all, This is my first bug report so please go easy on me if I screw it up. The kernel 2.4.6-ac1 The build machine AMD k6-2-350 with 128Megs of memory I get the following errors when I try to build ac1. It builds ok when just building 2.4.6 with the same config file run through make old_config, so I guess this is some kind of problem with ac1. make[2]: Entering directory `/usr/src/linux-2.4.6-ac1/arch/i386/lib' make[2]: Nothing to be done for `all_targets'. make[2]: Leaving directory `/usr/src/linux-2.4.6-ac1/arch/i386/lib' make[1]: Leaving directory `/usr/src/linux-2.4.6-ac1/arch/i386/lib' ld -m elf_i386 -T /usr/src/linux-2.4.6-ac1/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \ --start-group \ arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \ drivers/parport/driver.o drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/ide/idedriver.o drivers/cdrom/driver.o drivers/pci/driver.o drivers/video/video.o \ net/network.o \ /usr/src/linux-2.4.6-ac1/arch/i386/lib/lib.a /usr/src/linux-2.4.6-ac1/lib/lib.a /usr/src/linux-2.4.6-ac1/arch/i386/lib/lib.a \ --end-group \ -o vmlinux drivers/parport/driver.o: In function `parport_pc_find_ports': drivers/parport/driver.o(.text.init+0x10b4): undefined reference to `init_pnp040x' drivers/parport/driver.o(.text.init+0x10c2): undefined reference to `pnpbios_find_device' drivers/parport/driver.o(.text.init+0x10d2): undefined reference to `init_pnp040x' drivers/parport/driver.o(.text.init+0x10e0): undefined reference to `pnpbios_find_device' make: *** [vmlinux] Error 1 Make bzImage failed !!! The config file follows: # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set CONFIG_M586=y # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_USE_STRING_486=y CONFIG_X86_ALIGNMENT_16=y # CONFIG_TOSHIBA is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_SMP is not set CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y # CONFIG_PM is not set # CONFIG_ACPI is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=y CONFIG_PARPORT_PC=y CONFIG_PARPORT_PC_CML1=y # CONFIG_PARPORT_SERIAL is not set CONFIG_PARPORT_PC_FIFO=y # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_GSC is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play configuration # # CONFIG_PNP is not set # CONFIG_ISAPNP is not set # CONFIG_PNPBIOS is not set # # Block devices # CONFIG_BLK_DEV_FD=m # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=m # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_BLK_DEV_LVM is not set # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_NETLINK_DEV=y #
[PATCH #2] OOM kill trigger
Hi,
As Hugh pointed out, the info on how many pages we have in the
swap cache is (of course) present in the swapper_space structure.
Patch has been shrunk accordingly...
Rik
--
Executive summary of a recent Microsoft press release:
"we are concerned about the GNU General Public License (GPL)"
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com/
--- linux-2.4.6/mm/oom_kill.c.orig Fri Jul 6 17:32:58 2001
+++ linux-2.4.6/mm/oom_kill.c Fri Jul 6 19:19:25 2001
@@ -191,11 +191,28 @@
*/
int out_of_memory(void)
{
+ long cache_mem, limit;
+
/* Enough free memory? Not OOM. */
if (nr_free_pages() > freepages.min)
return 0;
if (nr_free_pages() + nr_inactive_clean_pages() > freepages.low)
+ return 0;
+
+ /*
+* If the buffer and page cache (excluding swap cache) are over
+* their (/proc tunable) minimum, we're still not OOM. We test
+* this to make sure we don't return OOM when the system simply
+* has a hard time with the cache.
+*/
+ cache_mem = atomic_read(_cache_size);
+ cache_mem += atomic_read(_pages);
+ cache_mem -= swapper_space.nrpages;
+ limit = (page_cache.min_percent + buffer_mem.min_percent);
+ limit *= num_physpages / 100;
+
+ if (cache_mem > limit)
return 0;
/* Enough swap space left? Not OOM. */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: What are rules for acpi_ex_enter_interpreter?
On Thu, Jul 05, 2001 at 04:05:43PM -0700, Grover, Andrew wrote: > Thanks for the report on the locking issue. A fix is checked in locally. > > > From: Petr Vandrovec [mailto:[EMAIL PROTECTED]] > > Replying to myself, after following change in additon to acpi_ex_... > > poweroff on my machine works. It should probably map type 0 > > => 0, 3 => 1 > > and 7 => 2, but it is hard to decide without VIA datasheet, so change > > below is minimal change needed to get poweroff through ACPI > > to work on my > > ASUS A7V. > > How did you discover slp typ values of 2 worked, where 7 did not? Did you > just try all possibilities (0-7)? Yes, in Borland TurboDebugger under MSDOS. 0 and 7 do nothing, 1 power offs, but power led blinks and I was not able to get machine back to life without unplugging power cord (it did not react to reset or power button). Maybe when it is correctly suspended, or when there is running ACPI interpreter, it can return back to life, but not under MSDOS. 2 power offs and LED is off 3 did nothing and 4-6 locked machine up just after outw(). Maybe it does something, but when tried from TD it just stopped react to anything (incl. poweroff) except reset button. If bit 0x2000 is not set, it does nothing, and if you write random values to SLP port, it somehow switches to another mode where it reads back as 0x and does not react to any outw values :-( Reset fixes this state... I hope that I remember states 3-6 correctly, but at least two of them are lockup, and at least one of them was nothing. But I'm 100% sure on 0,1,2 and 7. Best regards, Petr Vandrovec [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 don't recognize HD>1Gb on Sparc IPX
I put a 1.2Gb HD on my Sparc IPX but linux kernel recognized only 1Gb. Can Sparc IPX see more than 1Gb SCSI Hard Drives? Thanks Rafael Diniz Brazil Debian GNU/Linux 2.2 Potato(2.2.20-pre1) XFree86-3.3.6 PII 233mhz 96Mb ram SB16, USR56k, S3 VirgeDX/GX 4Mb vram, CD creative48X HDa 10.2Gb Quantum HDb 10.2Gb WD MSX2.0 256k MegaRam 256k Mapper v9938 128k Vram MSX is the future - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] OOM kill trigger fix
On Fri, 6 Jul 2001, Hugh Dickins wrote: > On Fri, 6 Jul 2001, Rik van Riel wrote: > > > > Of course, to implement this we have to count the number of > > swapcache pages, but that's a 2-liner ;) > > swapper_space.nrpages already counts that (as Andrea once > pointed out), no need to add your nr_swapcache_pages. Whoops, indeed... Rik -- Executive summary of a recent Microsoft press release: "we are concerned about the GNU General Public License (GPL)" http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] more SAK stuff
>More interestingly, it changes the operation of SAK in two ways: >(a) It does less, namely will not kill processes with uid 0. I think this is bad for security. (I assume you meant euid 0, not ruid 0. Using the real uid for access control decisions is a very odd thing to do.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: funky tyan s2510
I have had this happen to me on a very old machine whose CPU fan died at one point without notice and something burned out - the machine was working but crashing at random with all sorts of messages and in all sorts of situations, usually some time after startup (but not too long after startup). Best regards, Ognen On Fri, 6 Jul 2001, josh wrote: > > I have a tyan s2510 with a single pIII 800Mhz cpu and 1GB of RAM. > I have been having problems with this system from the get go and > cant seem to narrow down what the problem is. I have tried running > 2.4.6, but the system usually doesnt last more than a day. With > 2.4.2 i get a variety of kernel messages: > # > vs-5150: search_by_key: invalid format found in block 0. Fsck? > vs-13050: reiserfs_update_sd: i/o failure occurred trying to update [59906829 0x0 >SD] stat datavs-13060: reiserfs_update_sd: stat data of object [10616 10762 0x0 SD] >(nlink == 1) not found (pos 6) > vs-13060: reiserfs_update_sd: stat data of object [8766 9018 0x0 SD] (nlink == 1) >not found (pos 0) > vs-13060: reiserfs_update_sd: stat data of object [8766 8959 0x0 SD] (nlink == 1) >not found (pos 12) > vs-13060: reiserfs_update_sd: stat data of object [8766 8959 0x0 SD] (nlink == 1) >not found (pos 12) > memory.c:303: bad pmd 8524468b. > memory.c:83: bad pmd 831074c0. > memory.c:83: bad pmd 8524468b. > memory.c:83: bad pmd 831074c0. > memory.c:83: bad pmd 8524468b. > memory.c:83: bad pmd 831074c0. > memory.c:83: bad pmd 8524468b. > memory.c:83: bad pmd 831074c0. > kernel BUG at inode.c:79! > invalid operand: > CPU:0 > EIP:0010:[] > EFLAGS: 00010282 > eax: 001a ebx: f5e3c2a0 ecx: d99ae000 edx: > esi: c027e120 edi: dc12a620 ebp: d99affa4 esp: d99aff44 > ds: 0018 es: 0018 ss: 0018 > Process rm (pid: 13400, stackpage=d99af000) > Stack: c02301a5 c0230225 004f f5e3c2a0 c01428b6 f5e3c2a0 dc12a620 f5e3c2a0 >c01413c6 f5e3c2a0 f5d1ea00 c013b1fc dc12a620 dc12a620 dc12a620 >d82e c013b2d3 f5d1ea00 dc12a620 d99ae000 be82 bc48 > Call Trace: [] [] [] [] [] > > Code: 0f 0b 83 c4 0c a1 90 09 2d c0 53 50 e8 d9 65 fe ff 83 c4 08 > > > gcc never gets all the way through a make... it will die with a > sig11, misc asm errors, or random crap. > > This is a serverworks chipset... i have always thought that they were > a bit, you know, funny. :) > > Any ideas? -- Ognen Duzlevski Plant Biotechnology Institute National Research Council of Canada Bioinformatics team - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] OOM kill trigger fix
On Fri, 6 Jul 2001, Rik van Riel wrote: > > Of course, to implement this we have to count the number of > swapcache pages, but that's a 2-liner ;) swapper_space.nrpages already counts that (as Andrea once pointed out), no need to add your nr_swapcache_pages. Hugh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM Requirement Document - v0.0
On Friday 06 July 2001 21:09, Rik van Riel wrote: > On Thu, 5 Jul 2001, Daniel Phillips wrote: > > Let me comment on this again, having spent a couple of minutes > > more thinking about it. Would you be happy paying 1% of your > > battery life to get 80% less sluggish response after a memory > > pig exits? > > Just to pull a few random numbers out of my ass too, > how about 50% of battery life for the same optimistic > 80% less sluggishness ? > > How about if it were only 30% of battery life? It's not as random as that. The idea being considered was: suppose a program starts up, goes through a period of intense, cache-sucking activity, then exits. Could we reload the applications it just displaced so that the disk activity to reload them doesn't have to take place the first time the user touches the keyboard/mouse. Sure, we obviously can, with how much complexity is another question entirely ;-) So probably, we could eliminate more than 80% of the latency we now see in such a situation, I was being conservative. Now what's the cost in battery life? Suppose it's a 128 meg machine, 1/3 filled with program text and data. Hopefully, the working sets that were evicted are largely coherent so we'll read it back in at a rate not too badly degraded from the drive's transfer rate, say 5 MB/sec. This gives about three seconds of intense reading to restore something resembling the previous working set, then the disk can spin down and perhaps the machine will suspend itself. So the question is, how much longer did the machine have to run to do this? Well, on my machine updatedb takes 5-10 minutes, so the 3 seconds of activity tacked onto the end of the episode amounts to less than 1%, and this is where the 1% figure came from. I'm not saying this would be an easy hack, just that it's possible and the numbers work. -- 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: Trouble Booting Linux PPC 2000 On Mac G4
On Fri, 6 Jul 2001, Tim McDaniel wrote: > I think what we are seeing is XBoot rather than yaboot and we tried just > about all conceivable "kernel options", as exposed by Xboot. When Xboot > comes up it shows a ramdisk_size=8192 as the only default parameter. > Rapidly growing to hate the non-intuitive nature of the MAC OS we are > not experts on the Mac OS. P.S. We are running Mac OS 9.1. > > Oops, We just discovered that Xboot does not work with MacOS 9.1 (geez) > you MUST use yaboot. > > > We will try the Q4 release. I endorse Debian PPC. LinuxPPC is a quadruple hack that has never worked properly on the three Macs I tried to inflict it upon. -jwb - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BIGMEM kernel question
> Ahh. That makes sense. So how can I change the chunk size from 64k to > something higher (I assume I could set it to 128k to effectively double > that 3GB to 6GB)? I think you misunderstand. If you want more than 3Gb you will have to map and unmap stuff yourself. You only have 3Gb of per process address space due to x86 weaknesses (lack of seperate kernel/user spaces without tlb flush overhead nightmares) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: why this 1ms delay in mdio_read? (cont'd from "are ioctl callssupposed to take this long?")
On Fri, 6 Jul 2001, Chris Friesen wrote: > Subject: why this 1ms delay in mdio_read? (cont'd from "are ioctl calls supposed to take this long?") > > The beginning of mdio_read() in tulip.c goes like this: > > static int mdio_read(struct device *dev, int phy_id, int location) ... > mdelay(1); /* One ms delay... */ Ackkk! What driver version? And who put this bogus delay in the code? Putting arbitrary delays in drivers is usually a sign that the someone didn't understand how to fix a bug and is just trying to wait it out. > The chip I'm using is the DEC 21143, which means that we skip over the two > conditional blocks, so the first thing that happens when we call this is to > wait around doing nothing for a millisecond. Is there some subtle > reason why we would want to wait around for a millisecond before doing > anything? Nope. None at all. Donald Becker [EMAIL PROTECTED] Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BIGMEM kernel question
On Fri, 6 Jul 2001, Eric Anderson wrote: > Ahh. That makes sense. So how can I change the chunk size from > 64k to something higher (I assume I could set it to 128k to > effectively double that 3GB to 6GB)? That won't work. The address space limitation is a HARDWARE limitation. What you _can_ do is put data in shared memory segments, which you map and unmap on demand. Moving memory management to user space is the only way to (more or less) get around the 4GB hardware limitation. regards, Rik -- Executive summary of a recent Microsoft press release: "we are concerned about the GNU General Public License (GPL)" http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] OOM kill trigger fix
Hi,
the patch below fixes a bug in the OOM killer where the killer
could kick in if the system is out of swap (or has no swap), is
not out of memory yet but simply has a hard time with the cache.
The solution is to test against page_cache.min_percent +
buffer_cache.min_percent, this way we:
1) don't oom_kill() anything if we still have enough memory
left
2) will run oom_kill() BEFORE the system really starts
thrashing so badly that it'll never reach oom_kill()
because of the thrashing
Of course, to implement this we have to count the number of
swapcache pages, but that's a 2-liner ;)
Please apply for the next (pre) kernel.
regards,
Rik
--
Executive summary of a recent Microsoft press release:
"we are concerned about the GNU General Public License (GPL)"
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com/
--- linux-2.4.6/mm/oom_kill.c.orig Fri Jul 6 17:32:58 2001
+++ linux-2.4.6/mm/oom_kill.c Fri Jul 6 18:15:59 2001
@@ -191,11 +191,28 @@
*/
int out_of_memory(void)
{
+ long cache_mem, limit;
+
/* Enough free memory? Not OOM. */
if (nr_free_pages() > freepages.min)
return 0;
if (nr_free_pages() + nr_inactive_clean_pages() > freepages.low)
+ return 0;
+
+ /*
+* If the buffer and page cache (excluding swap cache) are over
+* their (/proc tunable) minimum, we're still not OOM. We test
+* this to make sure we don't return OOM when the system simply
+* has a hard time with the cache.
+*/
+ cache_mem = atomic_read(_cache_size);
+ cache_mem += atomic_read(_pages);
+ cache_mem -= atomic_read(_swapcache_pages);
+ limit = (page_cache.min_percent + buffer_mem.min_percent);
+ limit *= num_physpages / 100;
+
+ if (cache_mem > limit)
return 0;
/* Enough swap space left? Not OOM. */
--- linux-2.4.6/mm/swap_state.c.origFri Jul 6 17:32:58 2001
+++ linux-2.4.6/mm/swap_state.c Fri Jul 6 17:34:59 2001
@@ -51,6 +51,8 @@
_aops,
};
+atomic_t nr_swapcache_pages = ATOMIC_INIT(0);
+
#ifdef SWAP_CACHE_INFO
unsigned long swap_cache_add_total;
unsigned long swap_cache_del_total;
@@ -82,6 +84,7 @@
flags = page->flags & ~((1 << PG_error) | (1 << PG_arch_1));
page->flags = flags | (1 << PG_uptodate);
add_to_page_cache_locked(page, _space, entry.val);
+ atomic_inc(_swapcache_pages);
}
static inline void remove_from_swap_cache(struct page *page)
@@ -96,6 +99,7 @@
PageClearSwapCache(page);
ClearPageDirty(page);
__remove_inode_page(page);
+ atomic_dec(_swapcache_pages);
}
/*
--- linux-2.4.6/include/linux/swap.h.orig Fri Jul 6 17:33:07 2001
+++ linux-2.4.6/include/linux/swap.hFri Jul 6 17:33:34 2001
@@ -70,6 +70,7 @@
extern int nr_active_pages;
extern int nr_inactive_dirty_pages;
extern atomic_t nr_async_pages;
+extern atomic_t nr_swapcache_pages;
extern struct address_space swapper_space;
extern atomic_t page_cache_size;
extern atomic_t buffermem_pages;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Trouble Booting Linux PPC 2000 On Mac G4
I think what we are seeing is XBoot rather than yaboot and we tried just about all conceivable "kernel options", as exposed by Xboot. When Xboot comes up it shows a ramdisk_size=8192 as the only default parameter. Rapidly growing to hate the non-intuitive nature of the MAC OS we are not experts on the Mac OS. P.S. We are running Mac OS 9.1. Oops, We just discovered that Xboot does not work with MacOS 9.1 (geez) you MUST use yaboot. We will try the Q4 release. Thanks, Tim -Original Message- From: Jeffrey W. Baker [mailto:[EMAIL PROTECTED]] Sent: Friday, July 06, 2001 4:09 PM To: Tim McDaniel Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Trouble Booting Linux PPC On Mac G4 2000 On Fri, 6 Jul 2001, Tim McDaniel wrote: > > We are having a great degree of difficulty getting Linux PPC2 > running on a Mac G4 466 tower with 128MB of memory, One 30MB HD and one > CR RW. This is not a NuBus based system. To the best of our knowledge we > have followed the user manual to the tee, and even tried forcing video > settings at the Xboot screen. > > > But still, when we encounter the screen where you must chose between > MacOS and Linux and we chose linux, the screen goes black and for all > practical purposes the box appears to be locked. We've also tried > editing yaboot.conf but can't seem to save the new file. > > Any help would be greatly appreatiated. add "video=ofonly" to your boot command line. That is, at the yaboot "boot: " prompt, type "linux video=ofonly" If that doesn't work, try something else :) -jwb - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Initio 9100 Driver for Linux
On Fri, 6 Jul 2001 07:56:39, [EMAIL PROTECTED] wrote: > What I don't get about your patch is the following: Two things: 1) I must not try to type in patches while watching my phone bill to BT click up the pennies! 2) I must check the source I'm diffing against to make sure that Alan hasn't fixed the bug in the AC series already! ;-) -- Trevor Hemsley, Brighton, UK. [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: BIGMEM kernel question
Ahh. That makes sense. So how can I change the chunk size from 64k to something higher (I assume I could set it to 128k to effectively double that 3GB to 6GB)? Eric Anderson Alan Cox wrote: > > > kernel. My machine has 4GB of RAM, and 6GB of swap. It appears that I > > can only allocate 2930 MB (using heapc_linux and other programs). What > > do I need to do to get Linux to allow allocation of all available memory > > A non x86 based computer. Its basically impractical to map more than 3Gb of > memory to user space per process on x86. You can use mmap and shared memory > to do DOS EMS like tricks with gig rather than 64K sized chunks but you want > a real 64bit processor to go further > > Alan -- --- Eric Anderson[EMAIL PROTECTED]Centaur Technology(512) 418-5792 For every complex problem, there is a solution that is simple, neat, and wrong. --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NCR 35XXXX MCA bus and SMP
Hello Friends, my name is Paulo. And i have a NCR 3525 with MCA bus and 8 processors and 512MB RAM , i tried Suse 6.4 and Red Hat 7.1 , but nome detected my MCA bus , the 8 processors and more than 64MB ... i tried kernel parameter mem=512m , but no results... only 64MB i recompiled the kernel (2.4.2) with MCA=y and SMP =y ... and no results... somebody can help me ? Paulo Mateiro. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE0/Slave Detection Fails in 2.4.x(2.4.4, 2.4.5, and 2.4.5-ac18 tested)
Just an update: I have now tested it with the 2.4.6 kernel and the problem persists :( I failed to mention in the previous email that the machine is an 2 processor SMP machine. -Adam "Adam D. Scislowicz" wrote: > I am having a problem where the 2.4.x(2.4.4, and 2.4.5, and 2.4.5-ac18) > kernel does not detect the IDE0/primary slave device. If I put a third > drive in the system as IDE1/secondary master then that is detected. > However > the IDE0/primary slave is never detected. > > Using the 2.2.19 kernel the IDE0/primary slave device IS detected > properly. This > can be seen below in the 2.2.19 Kernel Init Messages. > > Below is some more detailed info. > *Note: Please CC me in any replay as I am not subscribed to this > mailiing list ;) > > -Adam Scislowicz > > [ My IDE Controller Info (2.2.19:/proc/pci) ] > Bus 0, device 7, function 1: > IDE interface: Intel 82371AB PIIX4 IDE (rev 1). > Medium devsel. Fast back-to-back capable. Master Capable. > Latency=64. > I/O at 0xffa0 [0xffa1]. > > [ The 2.2.19 Kernel Init Messages ] > PIIX4: IDE controller on PCI bus 00 dev 39 > PIIX4: not 100% native mode: will probe irqs later > ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:pio, hdb:DMA > ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio > hda: TOSHIBA THNCF032MAA, ATA DISK drive > hdb: IBM-DARA-206000, ATA DISK drive > hdc: ST320420A, ATA DISK drive > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > ide1 at 0x170-0x177,0x376 on irq 15 > hda: TOSHIBA THNCF032MAA, 31MB w/2kB Cache, CHS=496/4/32 > hdb: IBM-DARA-206000, 5729MB w/418kB Cache, CHS=730/255/63, UDMA > hdc: ST320420A, 19458MB w/2048kB Cache, CHS=39535/16/63, UDMA > > [ The 2.4.5-ac18 Kernel Init Messages ] > Uniform Multi-Platform E-IDE driver Revision: 6.31 > ide: Assuming 33MHz system bus speed for PIO modes; override with > idebus=xx > PIIX4: IDE controller on PCI bus 00 dev 39 > PIIX4: chipset revision 1 > PIIX4: not 100% native mode: will probe irqs later > ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:pio, hdb:DMA > ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio > hda: TOSHIBA THNCF032MAA, ATA DISK drive > hdc: ST320420A, ATA DISK drive > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > ide1 at 0x170-0x177,0x376 on irq 15 > hda: 63488 sectors (33 MB) w/2KiB Cache, CHS=496/4/32, DMA > hdc: 39851760 sectors (20404 MB) w/2048KiB Cache, CHS=39535/16/63, > UDMA(33) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Trouble Booting Linux PPC On Mac G4 2000
On Fri, 6 Jul 2001, Tim McDaniel wrote: > > We are having a great degree of difficulty getting Linux PPC2 > running on a Mac G4 466 tower with 128MB of memory, One 30MB HD and one > CR RW. This is not a NuBus based system. To the best of our knowledge we > have followed the user manual to the tee, and even tried forcing video > settings at the Xboot screen. > > > But still, when we encounter the screen where you must chose between > MacOS and Linux and we chose linux, the screen goes black and for all > practical purposes the box appears to be locked. We've also tried > editing yaboot.conf but can't seem to save the new file. > > Any help would be greatly appreatiated. add "video=ofonly" to your boot command line. That is, at the yaboot "boot: " prompt, type "linux video=ofonly" If that doesn't work, try something else :) -jwb - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BIGMEM kernel question
Eric Anderson wrote: > > I am currently running a RedHat 7.1 machine with the 2.4.3-12enterprise > kernel. My machine has 4GB of RAM, and 6GB of swap. It appears that I > can only allocate 2930 MB (using heapc_linux and other programs). What > do I need to do to get Linux to allow allocation of all available memory > (up to the 4GB)? All the FAQs I have seen so far explain only how to > get Linux to recognize the 4GB, and not use it all in one process. Any > help would be greatly appreciated. On a 32-bit architecture, Linux gives each user process 3GB of virtual address space. Into that 3GB address space you need to map your stack, exectuable images, shared libaries, etc. with the rest left for the heap. If you need more memory in a single process you're better off moving to a 64-bit architecture. Note that multiple processes, as well as the various caches can use the remaining memory. -- Brian Gerst - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BIGMEM kernel question
> kernel. My machine has 4GB of RAM, and 6GB of swap. It appears that I > can only allocate 2930 MB (using heapc_linux and other programs). What > do I need to do to get Linux to allow allocation of all available memory A non x86 based computer. Its basically impractical to map more than 3Gb of memory to user space per process on x86. You can use mmap and shared memory to do DOS EMS like tricks with gig rather than 64K sized chunks but you want a real 64bit processor to go further 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: Trouble Booting Linux PPC On Mac G4 2000
We are having a great degree of difficulty getting Linux PPC2 running on a Mac G4 466 tower with 128MB of memory, One 30MB HD and one CR RW. This is not a NuBus based system. To the best of our knowledge we have followed the user manual to the tee, and even tried forcing video settings at the Xboot screen. But still, when we encounter the screen where you must chose between MacOS and Linux and we chose linux, the screen goes black and for all practical purposes the box appears to be locked. We've also tried editing yaboot.conf but can't seem to save the new file. Any help would be greatly appreatiated. Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BIGMEM kernel question
I am currently running a RedHat 7.1 machine with the 2.4.3-12enterprise kernel. My machine has 4GB of RAM, and 6GB of swap. It appears that I can only allocate 2930 MB (using heapc_linux and other programs). What do I need to do to get Linux to allow allocation of all available memory (up to the 4GB)? All the FAQs I have seen so far explain only how to get Linux to recognize the 4GB, and not use it all in one process. Any help would be greatly appreciated. Please CC this email address in any responses. Thanks! Eric Anderson - Here is my /proc/meminfo: total:used:free: shared: buffers: cached: Mem: 3824029696 69316608 37547130880 3624960 20070400 Swap: 2145296384 4096 2145292288 MemTotal: 3734404 kB MemFree: 3666712 kB MemShared: 0 kB Buffers: 3540 kB Cached: 19600 kB Active: 22328 kB Inact_dirty: 812 kB Inact_clean: 0 kB Inact_target: 4664 kB HighTotal: 2883036 kB HighFree: 2850584 kB LowTotal: 851368 kB LowFree:816128 kB SwapTotal: 6289320 kB SwapFree: 6289316 kB -- --- Eric Anderson[EMAIL PROTECTED]Centaur Technology(512) 418-5700 For every complex problem, there is a solution that is simple, neat, and wrong. --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: funky tyan s2510
> > 2.4.2 i get a variety of kernel messages: > > # > > vs-5150: search_by_key: invalid format found in block 0. Fsck? > > IDE on a serverworks chipset ? If so try Alan's latest patches for an > updated driver The serverworks IDE fixes dont fit the reports , and the gcc one so says 'hardware problem' - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange thread behaviour on 8-way x86 machine
On Fri, 6 Jul 2001, Sasha Pachev wrote: > On Friday 06 July 2001 13:24, Rik van Riel wrote: > > On Fri, 6 Jul 2001, Sasha Pachev wrote: > > > > > Upon further investigation and testing, it turned out that the kernel was > not > > > at fault - the problem was high mutex contention, which caused frequent > > > context switches, and the idle CPU was apparently from the scheduler > waiting > > > for the original CPU to become available too often. > > > > > > On a side note, it would be nice if a process could communicate > > > to the kernel that it would rather run on the first available > > > CPU than wait for the perfect one to become available. > > > > The kernel already does this. > > Thanks for the info. Would you mind proving a one line pointer > on how to tell this to the kernel? It always does this, by default. AFAIK you cannot turn it off. Rik -- Executive summary of a recent Microsoft press release: "we are concerned about the GNU General Public License (GPL)" http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: funky tyan s2510
In article <[EMAIL PROTECTED]> you wrote: > I have a tyan s2510 with a single pIII 800Mhz cpu and 1GB of RAM. > I have been having problems with this system from the get go and > cant seem to narrow down what the problem is. I have tried running > 2.4.6, but the system usually doesnt last more than a day. With > 2.4.2 i get a variety of kernel messages: > # > vs-5150: search_by_key: invalid format found in block 0. Fsck? IDE on a serverworks chipset ? If so try Alan's latest patches for an updated driver - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange thread behaviour on 8-way x86 machine
On Friday 06 July 2001 13:24, Rik van Riel wrote: > On Fri, 6 Jul 2001, Sasha Pachev wrote: > > > Upon further investigation and testing, it turned out that the kernel was not > > at fault - the problem was high mutex contention, which caused frequent > > context switches, and the idle CPU was apparently from the scheduler waiting > > for the original CPU to become available too often. > > > > On a side note, it would be nice if a process could communicate > > to the kernel that it would rather run on the first available > > CPU than wait for the perfect one to become available. > > The kernel already does this. Thanks for the info. Would you mind proving a one line pointer on how to tell this to the kernel? -- MySQL Development Team For technical support contracts, visit https://order.mysql.com/ __ ___ ___ __ / |/ /_ __/ __/ __ \/ / Sasha Pachev <[EMAIL PROTECTED]> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/ /_/ /_/\_, /___/\___\_\___/ Provo, Utah, USA <___/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: funky tyan s2510
On Fri, 6 Jul 2001, josh wrote: > Thats what I thought at first, but after going through three different > brands of memory and a new (slower) cpu, im not sure what to think. It could also be other peripherals like video or the NIC. I personally had Linux (2.0.x kernel, WAAAY back when...) flake out on me because of a bad D-Link DE-220 ISA NIC. -- Ignacio Vazquez-Abrams <[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: Why Plan 9 C compilers don't have asm("")
Yes, that was not easy to miss. I was simply being clear. The plan9 compiler, thus its take on inline asm, doesn't run on ia64 and alpha as far as I can see from the latest release. } NONE of my examples were about the x86. } } I gave the alpha as a specific example. The same issues are true on } ia64, sparc64, and mips64. How more "modern" can you get? Name _one_ } reasonably important high-end CPU that is more modern than alpha and } ia64.. } } On ia64, you probably end up with function calls costing even more than } alpha, because not only does the function call end up being a } synchronization point for the compiler, it also means that the compiler } cannot expose any parallelism, so you get an added hit from there. At } least with other CPU's that find the parallelism dynamically they can do } out-of-order stuff across function calls. Yes, that's how I saw it didn't relate to the topic at hand. I suggested measurement rather than theory to determine whether the branch washes out or not. "Everyone knows" is a much weaker statement than "I can show". } Did you READ my mail at all? I definitely agree there. If you need an instruction or two that the compiler doesn't offer then it's a loss to call a function and inline asm is worthwhile. If this is a common enough case it's worth the compiler adding inline asm support. I'm not sure how often that is. My own subjective experience has been that calls to such code are rare enough that they fall well into the realm of optimization the uncommon case. I've used inline asm gratuitously in linux (it's peppered all over the ppc code) because I had the feature. I don't think that's a strong argument for adding it to a compiler that doesn't support it, though. } There are lots of good arguments for function calls: they improve icache } when done right, but if you have some non-C-semantics assembler sequence } like "cli" or a spinlock that you use a function call for, that would } _decrease_ icache effectiveness simply because the call itself is bigger } than the instruction (and it breaks up the instruction sequence so you } get padding issues). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.6: Machine Check Exception: 0x 106BE0 (type 0x 9).
On Wed, 4 Jul 2001, David Thor Bragason wrote: > Hello, I have the exact same exception on an LTE 5280 (32 MB RAM). AFAIK it only differs from the 5200 by a slightly larger screen. The machine works fine with the MCE initialisation commented out (or with a 2.2 series kernel) Frank > > I wrote to this list the other day about how I didn't get 2.4.5 to boot on > my Compaq LTE 5200 laptop. This is a Pentium 120MHz, 72MB RAM with an > OPTi Viper chipset. The strange thing is, all kernels up to 2.4.4 > (inclusive) compile and run flawlessly on this machine. Only when I tried > to upgrade to 2.4.5 did I get what looks like a hardware problem, and the > machine does not boot. There is nothing wrong with the kernel > configuration, and I tried gcc 2.95, 3.0, and, to be absolutely sure, > 2.91.66 (the recommended compiler). I then had the same problem with a > 2.4.6pre kernel, and, today, with the 2.4.6. > > The error message I'm getting now is: > > CPU#0: Machine Check Exception: 0x 106BE0 (type 0x 9). > > This line is repeated over and over again (with the spaces). > > There are some lines that fly by before that, though, and I went to some > lengths trying to capture them the other day. (They scroll by too fast to > be seen.) First I tried to set CONFIG_LP_CONSOLE and pass the appropriate > line to lilo, but nothing came out of > the printer. Then I tried lkcd (the kernel debugging patch/tool), but it > seems that the machine hangs too early in the boot process for that tool > to work. If the message above doesn't mean anything to anyone, I guess > I'll have to rent a videocamera and tape my laptop trying to boot :) > > I stress that 2.4.4 still compiles and runs without a problem. Does this > make any sense for a hardware problem? Was there any new hardware (cpu) > check introduced in 2.4.5? I'd be very grateful for any tips, > and could you please cc: them to me, as I don't subscribe to this > list. Thanks! > > David Bragason, > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > HI! I'm a .signature virus! cp me into your .signature file to help me spread! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: funky tyan s2510
On Fri, 6 Jul 2001, Alan Cox wrote: > > gcc never gets all the way through a make... it will die with a > > sig11, misc asm errors, or random crap. > > If its doing that at random then suspect hardaware Thats what I thought at first, but after going through three different brands of memory and a new (slower) cpu, im not sure what to think. > > This is a serverworks chipset... i have always thought that they were > > a bit, you know, funny. :) > > Serverworks have an obscure MTRR bug in a few chips (which we handle) but > quite honestly they don't show up a lot in kernel bug reports. I actually like SW chipsets... they do some neat things... more than me at least. www.mammoth.org/~skulcap **BEGIN GEEK CODE BLOCK "Sometimes, if you're perfectly * GCS d- s: a-- C++ ULSC$ P+ L+++ E--- still, you can hear the virgin * W+(++) N++ o+ K- w--(---) O- M- V- PS-- weeping for the savior of your will."* PE Y+ PGP t+ 5 X+ R !tv b+>+++ DI++ D++ --DreamTheater, "Lines in the Sand" * G e h+ r-- y- (www.geekcode.com) **END GEEK CODE BLOCK** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: funky tyan s2510
> gcc never gets all the way through a make... it will die with a > sig11, misc asm errors, or random crap. If its doing that at random then suspect hardaware > This is a serverworks chipset... i have always thought that they were > a bit, you know, funny. :) Serverworks have an obscure MTRR bug in a few chips (which we handle) but quite honestly they don't show up a lot in kernel bug reports. 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/
funky tyan s2510
I have a tyan s2510 with a single pIII 800Mhz cpu and 1GB of RAM. I have been having problems with this system from the get go and cant seem to narrow down what the problem is. I have tried running 2.4.6, but the system usually doesnt last more than a day. With 2.4.2 i get a variety of kernel messages: # vs-5150: search_by_key: invalid format found in block 0. Fsck? vs-13050: reiserfs_update_sd: i/o failure occurred trying to update [59906829 0x0 SD] stat datavs-13060: reiserfs_update_sd: stat data of object [10616 10762 0x0 SD] (nlink == 1) not found (pos 6) vs-13060: reiserfs_update_sd: stat data of object [8766 9018 0x0 SD] (nlink == 1) not found (pos 0) vs-13060: reiserfs_update_sd: stat data of object [8766 8959 0x0 SD] (nlink == 1) not found (pos 12) vs-13060: reiserfs_update_sd: stat data of object [8766 8959 0x0 SD] (nlink == 1) not found (pos 12) memory.c:303: bad pmd 8524468b. memory.c:83: bad pmd 831074c0. memory.c:83: bad pmd 8524468b. memory.c:83: bad pmd 831074c0. memory.c:83: bad pmd 8524468b. memory.c:83: bad pmd 831074c0. memory.c:83: bad pmd 8524468b. memory.c:83: bad pmd 831074c0. kernel BUG at inode.c:79! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00010282 eax: 001a ebx: f5e3c2a0 ecx: d99ae000 edx: esi: c027e120 edi: dc12a620 ebp: d99affa4 esp: d99aff44 ds: 0018 es: 0018 ss: 0018 Process rm (pid: 13400, stackpage=d99af000) Stack: c02301a5 c0230225 004f f5e3c2a0 c01428b6 f5e3c2a0 dc12a620 f5e3c2a0 c01413c6 f5e3c2a0 f5d1ea00 c013b1fc dc12a620 dc12a620 dc12a620 d82e c013b2d3 f5d1ea00 dc12a620 d99ae000 be82 bc48 Call Trace: [] [] [] [] [] Code: 0f 0b 83 c4 0c a1 90 09 2d c0 53 50 e8 d9 65 fe ff 83 c4 08 gcc never gets all the way through a make... it will die with a sig11, misc asm errors, or random crap. This is a serverworks chipset... i have always thought that they were a bit, you know, funny. :) Any ideas? www.mammoth.org/~skulcap **BEGIN GEEK CODE BLOCK "Sometimes, if you're perfectly * GCS d- s: a-- C++ ULSC$ P+ L+++ E--- still, you can hear the virgin * W+(++) N++ o+ K- w--(---) O- M- V- PS-- weeping for the savior of your will."* PE Y+ PGP t+ 5 X+ R !tv b+>+++ DI++ D++ --DreamTheater, "Lines in the Sand" * G e h+ r-- y- (www.geekcode.com) **END GEEK CODE BLOCK** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: why this 1ms delay in mdio_read? (cont'd from "are ioctl calls supposed to take this long?")
"Richard B. Johnson" wrote:
>
> On Fri, 6 Jul 2001, Chris Friesen wrote:
> > mdelay(1); /* One ms delay... */
> >
> > ...rest of code...
> >
>
> What? What kernel version?
> The code here says:
> /* Establish sync by sending at least 32 logic ones */
> for (i = 32; i >=0; i--) {..}
I had assumed that it was part of the normal drivers, but now after digging into
it some more it appears to have been added as part of a patch from Motorola for
a compact PCI board. I can't see why they would have done this but I'm trying
to track it down now.
Thanks for all your help,
Chris
--
Chris Friesen| MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada| email: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Uncle Sam Wants YOU!
On Fri, 6 Jul 2001, Tracy R Reed wrote: > On Sun, Jul 01, 2001 at 04:53:25PM -0700, Ben Ford wrote: > > I seem to recall that MS products cannot be used in aircraft control > > rooms for this reason. > > Your statement above is not necessarily true. By control rooms do you mean > control towers or in the aircraft themselves? Inside the aircraft itself > is obviously the more critical situation and NT is being used there so I > don't see why it wouldn't be used in the air traffic control system as > well whether it be in control towers, air route traffic control centers, > or wherever. > > MS products are used in life-critical situations. First, there was the > USS Yorktown. But that was just a test situation. > > Here is an NT system used in a real non-test and FAA certified situation. > It operates the primary flight instruments of a high-performance aircraft. > There are several certified aircraft using this unit. I can't remember the > others I've read about but this is the Lancair Columbia 400. > > From http://www.avweb.com/articles/colum400/ : [SNIPPED most of the rest] It's Windows/CE. It takes a few seconds to boot from NVRAM. It's used in Honeywell Flight Directors (for the FP display). It's not like it was life-critical, you still have (required) steam gages for backup. It is probably more reliable than the mechanical backups because, except for the bugs, it has no moving parts. > Wouldn't want to pull a Kennedy! Don't bet on it. I'm not a Kennedy supporter, but the "rich kid" went to the best and most expensive flight school in America. He had already passed the Instrument written exam. He had more flight instruction than many ATPs and the instruction was modern which means he seldom looked out the window (a pet peeve of mine), doing about everything by reference to instruments. FYI. The horizontal stabilizer was not with the airplane when it was recovered; The damage was impact damage from hitting water dead-nuts vertical; The loss of control occurred while leveling off during a routine descent. Regardless of what the politicians at the NTSB say, this looks to me like the AC shed its tail, resulting in an unrecoverable loss of control. Of course, what do I know. I'm only a commercial pilot/Inst with a little over 3,000 hours over the past 30 years. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). I was going to compile a list of innovations that could be attributed to Microsoft. Once I realized that Ctrl-Alt-Del was handled in the BIOS, I found that there aren't any. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange thread behaviour on 8-way x86 machine
On Fri, 6 Jul 2001, Sasha Pachev wrote: > Upon further investigation and testing, it turned out that the kernel was not > at fault - the problem was high mutex contention, which caused frequent > context switches, and the idle CPU was apparently from the scheduler waiting > for the original CPU to become available too often. > > On a side note, it would be nice if a process could communicate > to the kernel that it would rather run on the first available > CPU than wait for the perfect one to become available. The kernel already does this. Rik -- Executive summary of a recent Microsoft press release: "we are concerned about the GNU General Public License (GPL)" http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linus vs. AC kernels
> Adam wrote: > > > yeah, read change logs.. > > > Some samples. > > -pre9: > - merge with Alan (including MIPS update) > > -pre6: > - Alan Cox: merging, merging, merging It might be helpful if these types of notes could indicate the version from the other source tree that these changes come from. For example 'merge with Alan (patches mostly in his ac13)'. I do realize that you can't draw exact parallels. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM Requirement Document - v0.0
On Thu, 5 Jul 2001, Daniel Phillips wrote: > Let me comment on this again, having spent a couple of minutes > more thinking about it. Would you be happy paying 1% of your > battery life to get 80% less sluggish response after a memory > pig exits? Just to pull a few random numbers out of my ass too, how about 50% of battery life for the same optimistic 80% less sluggishness ? How about if it were only 30% of battery life? Rik -- Executive summary of a recent Microsoft press release: "we are concerned about the GNU General Public License (GPL)" http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Via82cxxx Codec rate locked at 48Khz
Ariel Molina Rueda wrote: > > Greetings: > > When i used Redhat 7 and kernel 2.2.x y was happy with my souncard, now I > use RedHat 7.1 and Kernel 2.4.x, but sndconfig doesn't configure my > Via82c686 soundcard at all. At the ending it says > > via82cxxx codec rate locked at 48khz > > I use a Biostar MKE401B Matherboard with on-board sound (AC97) > > I've heard about patches for the intel chipsets, does anybody knows if one > for my card has been released, or how to fix this problem... > (my sound is choppy and XMMS crashes!) > > something weird is that sound is good when Linus says: > "Hi, Im Linus Torvalds, and" > then after sndconfig ends and sound is crying... Kernel 2.4.6 definitely includes fixes. For the message "Codec rate locked at 48Khz", that is a hardware limitation of your codec. You need to find software which supports software rate conversion, so that you may play music at speeds other than 48Khz. Jeff -- Jeff Garzik | A recent study has shown that too much soup Building 1024| can cause malaise in laboratory mice. MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Uncle Sam Wants YOU!
On Sun, Jul 01, 2001 at 09:09:32PM -0400, William T Wilson wrote: > It's not just MS. Aircraft control rooms (as well as nuclear power > plants, spacecraft mission control, etc.) require special certified > software to be used - it's not simply that they avoid MS, they avoid all > software that hasn't been blessed. Not true. The FAA is certifying NT in aircraft. See the message I just sent. -- Tracy Reed http://www.ultraviolet.org "Bill Gates is a white Persian cat and a monocle away from becoming another James Bond villain." "No Mr Bond, I expect you to upgrade." --Dennis Miller PGP signature
Re: Uncle Sam Wants YOU!
On Sun, Jul 01, 2001 at 04:53:25PM -0700, Ben Ford wrote: > I seem to recall that MS products cannot be used in aircraft control > rooms for this reason. Your statement above is not necessarily true. By control rooms do you mean control towers or in the aircraft themselves? Inside the aircraft itself is obviously the more critical situation and NT is being used there so I don't see why it wouldn't be used in the air traffic control system as well whether it be in control towers, air route traffic control centers, or wherever. MS products are used in life-critical situations. First, there was the USS Yorktown. But that was just a test situation. Here is an NT system used in a real non-test and FAA certified situation. It operates the primary flight instruments of a high-performance aircraft. There are several certified aircraft using this unit. I can't remember the others I've read about but this is the Lancair Columbia 400. From http://www.avweb.com/articles/colum400/ : >Stationary is the word until the system boots -- perhaps like the computer >you're using to read this -- and the solid-state AHARS (attitude, heading >and reference system) sensors orient. Of course, this slight delay (the >avionics system uses an even more stable version of Microsoft's >almost-bulletproof Windows NT) generally won't pose a problem during cold >starts -- particularly cold-weather cold starts. I gasped aloud when I read "almost-bulletproof Windows NT". As a pilot who flies people into the clouds regularly (San Diego usually has good weather but only after the marine layer clears) I can tell you that a reliable attitude indicator (AI) is an absolute life-critical necessity. Without one, you are in serious trouble. When inside a cloud without visual reference to the ground all you see out the windows is whiteness. It's like being on the inside of a giant white sphere with no markings whatsoever. Or blackness if at night. If the attitude indicator fails vertigo often sets in as you can't tell which way is up as your brain, confused by the unnatural state of not having any visual reference to the horizon, tells you incorrect things. You can't just drop a penny and see which way it falls or hang a string from the ceiling and see which way it hangs or look at the level of water in a glass to see what is level. The aircraft will be turning steeply (left or right, you have no way of knowing and banking the aircraft the wrong way will only make it much worse very fast) which means it is being accelerated towards the inside of the turn so the penny may fall straight down, the string may hang straight, and the water in the glass might be level. Whatever these things are doing, they won't be right. You will be descending very quickly now since the lift of the steeply banked wings is being generated horizontally instead of vertically, tightening the turn. This continues until impact. You have absolutely no way to tell which way is up or which way you are turning without a stable gyroscopic reference. It is my (and every pilots) worst nightmare when flying in clouds or anytime the outside horizon is not clearly visible. Yes, there are instruments which can be used to derive attitude information such as rate of turn, altimeter, vertical speed indicator, etc. (assuming they aren't driven by the same crashed computer as the AI) and this is standard procedure in the case of AI failure but it takes lots of practice to be able to use them because the information they provide you with is indirect and requires interpretation. Not an easy thing to do when you know you are in serious trouble. Missouri Governer Mel Carnahan was killed in a plane crash recently where the attitude indicator failed and the pilot had to interpret the other instruments to get attitude info and wasn't able to cut it. The article quoted above claims that this is a special version of NT that really is stable...no we really mean it this time! Why they don't make this especially stable version available to consumers is beyond me...oh wait, I know why: because it's really just the same code everyone runs on their servers and desktops! Fortunately, this system only runs for a few hours at a time and gets shut down/rebooted after every flight. It also runs only one application and never has any new software installed or uninstalled. No network access either. That should help a lot with reliability. I hope this thing doesn't have a hard drive in it. The gyroscopic effects on the platter of a pitching aircraft can't be good for the bearings. This equipment is so expensive that it is expected to last many years, even decades. Who is going to support NT 20 years from now? This setup was approved and certified for use by the FAA. I wonder if any software engineers looked at it? I'll have to find out what criteria they use for certifying this sort of thing. It must use an x86 processor too. I sure hope it has good cooling. I've already had one avionics failure due to
Re: why this 1ms delay in mdio_read? (cont'd from "are ioctl calls supposed to take this long?")
On Fri, 6 Jul 2001, Chris Friesen wrote:
> The beginning of mdio_read() in tulip.c goes like this:
>
> static int mdio_read(struct device *dev, int phy_id, int location)
> {
> struct tulip_private *tp = (struct tulip_private *)dev->priv;
> int i;
> int read_cmd = (0xf6 << 10) | (phy_id << 5) | location;
> int retval = 0;
> long ioaddr = dev->base_addr;
> long mdio_addr = ioaddr + CSR9;
>
> if (tp->chip_id == LC82C168) {
> int i = 1000;
> outl(0x6002 + (phy_id<<23) + (location<<18), ioaddr + 0xA0);
> inl(ioaddr + 0xA0);
> inl(ioaddr + 0xA0);
> while (--i > 0)
> if ( ! ((retval = inl(ioaddr + 0xA0)) & 0x8000))
> return retval & 0x;
> return 0x;
> }
>
> if (tp->chip_id == COMET) {
> if (phy_id == 1) {
> if (location < 7)
> return inl(ioaddr + 0xB4 + (location<<2));
> else if (location == 17)
> return inl(ioaddr + 0xD0);
> else if (location >= 29 && location <= 31)
> return inl(ioaddr + 0xD4 + ((location-29)<<2));
> }
> return 0x;
> }
>
> mdelay(1); /* One ms delay... */
>
> ...rest of code...
>
What? What kernel version?
The code here says:
/* Establish sync by sending at least 32 logic ones */
for (i = 32; i >=0; i--) {..}
There is a mdio_delay() between each of the bit operations. This
is required to give time for the chip's internals to set up.
There is no mdelay in any of the code in .../linux/drivers/net/tulip/.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Strange thread behaviour on 8-way x86 machine
On Tuesday 03 July 2001 12:51, Mike Kravetz wrote: > On Tue, Jul 03, 2001 at 12:25:12PM -0600, Sasha Pachev wrote: > > Hi, > > > > I have observed a rather strange behaviour doing a multi-threaded CPU > > benchmark on an 8-way machine running 2.4.2 SMP kernel. Even when the > > priority is reniced to the highest possible value, I am still unable to reach > > more than 50% CPU utilization. My benchmark just creates a bunch of threads > > with pthread_create(), and then runs a simple integer computation in each > > thread. On a dual with 2.4.3 kernel, and a 4-way with 2.4.2 kernel, I am able > > to reach full CPU utilization. > > I haven't had any problem fully utilizing 8 CPUs on 2.4.* kernels. This > may seem obvious, but do you have more than 4 CPUs worth of work for the > system to do? What is the runqueue length during this benchmark? Upon further investigation and testing, it turned out that the kernel was not at fault - the problem was high mutex contention, which caused frequent context switches, and the idle CPU was apparently from the scheduler waiting for the original CPU to become available too often. On a side note, it would be nice if a process could communicate to the kernel that it would rather run on the first available CPU than wait for the perfect one to become available. -- MySQL Development Team For technical support contracts, visit https://order.mysql.com/ __ ___ ___ __ / |/ /_ __/ __/ __ \/ / Sasha Pachev <[EMAIL PROTECTED]> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/ /_/ /_/\_, /___/\___\_\___/ Provo, Utah, USA <___/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why Plan 9 C compilers don't have asm("")
In article <[EMAIL PROTECTED]>, Cort Dougan <[EMAIL PROTECTED]> wrote: >I'm talking about _modern_ processors, not processors that dominate the >modern age. This isn't x86. NONE of my examples were about the x86. I gave the alpha as a specific example. The same issues are true on ia64, sparc64, and mips64. How more "modern" can you get? Name _one_ reasonably important high-end CPU that is more modern than alpha and ia64.. On ia64, you probably end up with function calls costing even more than alpha, because not only does the function call end up being a synchronization point for the compiler, it also means that the compiler cannot expose any parallelism, so you get an added hit from there. At least with other CPU's that find the parallelism dynamically they can do out-of-order stuff across function calls. >Unconditional branches are definitely predictable so icache pre-fetches are >not more complicated that straight-line code. Did you READ my mail at all? Most of these "unconditional branches" are indirect, because rather few 64-bit architectures have a full 64-bit branch. That means that in order to predict them, you either have to do data-prediction (pretty much nobody does this), or you have a branch target prediction cache, which works very well indeed but has the problem that it only works for stuff in the cache, and the cache tends to be fairly limited (because you need to cache the whole address - it's more than a "which direction do we go in"). There are lots of good arguments for function calls: they improve icache when done right, but if you have some non-C-semantics assembler sequence like "cli" or a spinlock that you use a function call for, that would _decrease_ icache effectiveness simply because the call itself is bigger than the instruction (and it breaks up the instruction sequence so you get padding issues). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
IDE0/Slave Detection Fails in 2.4.x(2.4.4, 2.4.5, and 2.4.5-ac18 tested)
I am having a problem where the 2.4.x(2.4.4, and 2.4.5, and 2.4.5-ac18) kernel does not detect the IDE0/primary slave device. If I put a third drive in the system as IDE1/secondary master then that is detected. However the IDE0/primary slave is never detected. Using the 2.2.19 kernel the IDE0/primary slave device IS detected properly. This can be seen below in the 2.2.19 Kernel Init Messages. Below is some more detailed info. *Note: Please CC me in any replay as I am not subscribed to this mailiing list ;) -Adam Scislowicz [ My IDE Controller Info (2.2.19:/proc/pci) ] Bus 0, device 7, function 1: IDE interface: Intel 82371AB PIIX4 IDE (rev 1). Medium devsel. Fast back-to-back capable. Master Capable. Latency=64. I/O at 0xffa0 [0xffa1]. [ The 2.2.19 Kernel Init Messages ] PIIX4: IDE controller on PCI bus 00 dev 39 PIIX4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:pio, hdb:DMA ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio hda: TOSHIBA THNCF032MAA, ATA DISK drive hdb: IBM-DARA-206000, ATA DISK drive hdc: ST320420A, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: TOSHIBA THNCF032MAA, 31MB w/2kB Cache, CHS=496/4/32 hdb: IBM-DARA-206000, 5729MB w/418kB Cache, CHS=730/255/63, UDMA hdc: ST320420A, 19458MB w/2048kB Cache, CHS=39535/16/63, UDMA [ The 2.4.5-ac18 Kernel Init Messages ] Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PIIX4: IDE controller on PCI bus 00 dev 39 PIIX4: chipset revision 1 PIIX4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:pio, hdb:DMA ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio hda: TOSHIBA THNCF032MAA, ATA DISK drive hdc: ST320420A, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 63488 sectors (33 MB) w/2KiB Cache, CHS=496/4/32, DMA hdc: 39851760 sectors (20404 MB) w/2048KiB Cache, CHS=39535/16/63, UDMA(33) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Via82cxxx Codec rate locked at 48Khz: ALSA
ALSA drivers have the same problem, i've already installed them... thanx On Fri, 6 Jul 2001, Masoud wrote: > On Fri, 6 Jul 2001, Ariel Molina Rueda wrote: > > > > > Greetings: > > > > When i used Redhat 7 and kernel 2.2.x y was happy with my souncard, now I > > use RedHat 7.1 and Kernel 2.4.x, but sndconfig doesn't configure my > > Via82c686 soundcard at all. At the ending it says > > > > via82cxxx codec rate locked at 48khz > > > > I use a Biostar MKE401B Matherboard with on-board sound (AC97) > > > > I've heard about patches for the intel chipsets, does anybody knows if one > > for my card has been released, or how to fix this problem... > > (my sound is choppy and XMMS crashes!) > > > > something weird is that sound is good when Linus says: > > "Hi, Im Linus Torvalds, and" > > then after sndconfig ends and sound is crying... > > > > > > You might consider using ALSA sound drivers. > (http://www.alsa-project.org). > Does any body know when they'd merge with mainstream kernel? > (or are they going to be merged with kernel at all or not?) > cheers, > Masoud Sharbiani > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- _ Ariel Molina Rueda [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/
why this 1ms delay in mdio_read? (cont'd from "are ioctl calls supposed to take this long?")
The beginning of mdio_read() in tulip.c goes like this:
static int mdio_read(struct device *dev, int phy_id, int location)
{
struct tulip_private *tp = (struct tulip_private *)dev->priv;
int i;
int read_cmd = (0xf6 << 10) | (phy_id << 5) | location;
int retval = 0;
long ioaddr = dev->base_addr;
long mdio_addr = ioaddr + CSR9;
if (tp->chip_id == LC82C168) {
int i = 1000;
outl(0x6002 + (phy_id<<23) + (location<<18), ioaddr + 0xA0);
inl(ioaddr + 0xA0);
inl(ioaddr + 0xA0);
while (--i > 0)
if ( ! ((retval = inl(ioaddr + 0xA0)) & 0x8000))
return retval & 0x;
return 0x;
}
if (tp->chip_id == COMET) {
if (phy_id == 1) {
if (location < 7)
return inl(ioaddr + 0xB4 + (location<<2));
else if (location == 17)
return inl(ioaddr + 0xD0);
else if (location >= 29 && location <= 31)
return inl(ioaddr + 0xD4 + ((location-29)<<2));
}
return 0x;
}
mdelay(1); /* One ms delay... */
...rest of code...
The chip I'm using is the DEC 21143, which means that we skip over the two
conditional blocks, so the first thing that happens when we call this is to
wait around doing nothing for a millisecond. Is there some subtle reason why we
would want to wait around for a millisecond before doing anything?
Thanks for your help,
Chris
--
Chris Friesen| MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada| email: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Via82cxxx Codec rate locked at 48Khz
The Kernel is 2.4.2-2 , the kernel that comes in the Redhat 7.1 Distro. Do you think its a good idea to update my kernel...? May that solve my problem...? i've heard that updating it's useless to fix this... BTW where can i found the latest STABLE Kernel? On Fri, 6 Jul 2001, Adrian Cox wrote: > Ariel Molina Rueda wrote: > > > > When i used Redhat 7 and kernel 2.2.x y was happy with my souncard, now I > > use RedHat 7.1 and Kernel 2.4.x, but sndconfig doesn't configure my > > Via82c686 soundcard at all. At the ending it says > > > > via82cxxx codec rate locked at 48khz > > > Is this with 2.4.6 or an earlier version? 2.4.6 contained new code for > talking to the codec. > > -- _ Ariel Molina Rueda [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: Via82cxxx Codec rate locked at 48Khz
On Fri, 6 Jul 2001, Ariel Molina Rueda wrote: > > Greetings: > > When i used Redhat 7 and kernel 2.2.x y was happy with my souncard, now I > use RedHat 7.1 and Kernel 2.4.x, but sndconfig doesn't configure my > Via82c686 soundcard at all. At the ending it says > > via82cxxx codec rate locked at 48khz > > I use a Biostar MKE401B Matherboard with on-board sound (AC97) > > I've heard about patches for the intel chipsets, does anybody knows if one > for my card has been released, or how to fix this problem... > (my sound is choppy and XMMS crashes!) > > something weird is that sound is good when Linus says: > "Hi, Im Linus Torvalds, and" > then after sndconfig ends and sound is crying... > > You might consider using ALSA sound drivers. (http://www.alsa-project.org). Does any body know when they'd merge with mainstream kernel? (or are they going to be merged with kernel at all or not?) cheers, Masoud Sharbiani - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: >128 MB RAM stability problems (again)
Hi all, On 05 Jul 2001 13:45:23 -0700, Peter A. Castro wrote: > Each OS allocates the physical memory differently. MS-Windows typically > allocates physical memory sequentually. Linux tends to uses both ends of > the memory pool. For a proper test, you need to load enough programs so > that all of physical memory will be utilized. Win2k may be "stable" > because you aren't loading enough of the system to touch the second bank > of memory. Please try running several large programs and exercise them > all together for several minutes. You can use the task manager to find > the total memory used on the system. Pheew (this is sarcastic) You're fully correct, after toying a bit on win2k, I crashed it a few times with weird errors and I must say, these blue screens in win2k look a *lot* better than the ones I used to see in win98 ;-). They still don't match that wonderful "kernel panic", though. So, basically, my bios must have loaded the wrong options for my memory which must run above it's limits which causes data corruption... Then, my stupid question, why doesn't memtest86 detect that? Anyway, I'll go look at the bios settings of the computers, look at the CAS/RAS/clock timing settings like two people suggested (thanks :-) ) and hope to be happy and have a stable machine after that. Thanks for this half-solution :-) -- Ronald Bultje - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Via82cxxx Codec rate locked at 48Khz
Ariel Molina Rueda wrote: > When i used Redhat 7 and kernel 2.2.x y was happy with my souncard, now I > use RedHat 7.1 and Kernel 2.4.x, but sndconfig doesn't configure my > Via82c686 soundcard at all. At the ending it says > > via82cxxx codec rate locked at 48khz Is this with 2.4.6 or an earlier version? 2.4.6 contained new code for talking to the codec. -- Adrian Cox http://www.humboldt.co.uk/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] 2.4.7-pre3 kernel_stat -> cpu_stat[NR_CPUS]
This patch does the following: - creates a cacheline aligned/padded struct cpu_stat[NR_CPUS]. - moves the [NR_CPUS] members of kernel_stat into cpu_stat This moves the stat data that a cpu will update into a contiguous region. Previous users of kernel_stat would compete for an array's cacheline with other cpus. - creates /proc/cpu/[0-9]+/ and fs/proc/proc_cpu.c with code for managing files in the cpu's directories. This should be useful for rusty's */active and arjan/rmk's */frequency. I have no strong feelings about where this lives or what it should be named. - adds collection of fault statistics and adds 'context migration' recording, per cpu. - updates users of kernel_stat in proc, reports shouldn't change - updates every friggin' user of kstat.irqs[] in arch/ with a macro so that we never have to do this again. The patch is rather large, due to that last bit. It can be found at http://www.osdlab.org/sw_resources/cpustat/cpustat-2.4.7.pre3-1.diff with a tool for summarizing /proc/cpu/*/stat at: http://www.osdlab.org/sw_resources/cpustat/index.shtml I'd like to get this sent to Linus soon, but wanted to run the /proc/cpu/* stuff by l-k one last time. - z - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Fix warnings in videobook
On Fri, Jul 06, 2001 at 06:26:14PM +0100, Alan Cox wrote: > > All of which can be fixed by changing <> into . Patch applies > > cleanly against 2.4.6, 2.4.7-pre3, and 2.4.6-ac1. Please apply, it even > > makes the tables visible :) > > That looks like tool problems. <> is valid SGML short format, are you > using XML docbook ? Not that I am aware of, I'm using the SGML packages in Debian Potato (2.2r3). > I'll apply them anyway - they do no harm and short form SGML is evil in some > books ;) Thanks. Erik [not an SGML language lawyer ;) ] -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Via82cxxx Codec rate locked at 48Khz
Greetings: When i used Redhat 7 and kernel 2.2.x y was happy with my souncard, now I use RedHat 7.1 and Kernel 2.4.x, but sndconfig doesn't configure my Via82c686 soundcard at all. At the ending it says via82cxxx codec rate locked at 48khz I use a Biostar MKE401B Matherboard with on-board sound (AC97) I've heard about patches for the intel chipsets, does anybody knows if one for my card has been released, or how to fix this problem... (my sound is choppy and XMMS crashes!) something weird is that sound is good when Linus says: "Hi, Im Linus Torvalds, and" then after sndconfig ends and sound is crying... -- _ Ariel Molina Rueda [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] Fix warnings in videobook
> All of which can be fixed by changing <> into . Patch applies > cleanly against 2.4.6, 2.4.7-pre3, and 2.4.6-ac1. Please apply, it even > makes the tables visible :) That looks like tool problems. <> is valid SGML short format, are you using XML docbook ? I'll apply them anyway - they do no harm and short form SGML is evil in some books ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Fix warnings in videobook
Hi,
This patch fixes the Jade SGML warnings when compiling the videobook:
jade:videobook.sgml:182:34:E: character data is not allowed here
jade:videobook.sgml:182:47:E: end tag for "ROW" which is not finished
jade:videobook.sgml:182:50:E: document type does not allow element "TBODY" here;
assuming missing "TGROUP" start-tag
jade:videobook.sgml:182:50:E: required attribute "COLS" not specified
jade:videobook.sgml:184:8:E: character data is not allowed here
jade:videobook.sgml:186:42:E: end tag for element "ENTRY" which is not open
jade:videobook.sgml:187:6:E: end tag for element "ROW" which is not open
All of which can be fixed by changing <> into . Patch applies
cleanly against 2.4.6, 2.4.7-pre3, and 2.4.6-ac1. Please apply, it even
makes the tables visible :)
Erik
--
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands
Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED]
WWW: http://www-ict.its.tudelft.nl/~erik/
Index: Documentation/DocBook/videobook.tmpl
===
RCS file: /home/erik/cvsroot/elinux/Documentation/DocBook/videobook.tmpl,v
retrieving revision 1.1.1.8
retrieving revision 1.1.1.8.28.1
diff -u -r1.1.1.8 -r1.1.1.8.28.1
--- Documentation/DocBook/videobook.tmpl2001/02/20 16:52:53 1.1.1.8
+++ Documentation/DocBook/videobook.tmpl2001/07/06 17:20:09 1.1.1.8.28.1
@@ -179,23 +179,23 @@
-VFL_TYPE_RADIO<>/dev/radio{n}<>
+VFL_TYPE_RADIO/dev/radio{n}
Radio devices are assigned in this block. As with all of these
selections the actual number assignment is done by the video layer
accordijng to what is free.
-VFL_TYPE_GRABBER<>/dev/video{n}<>
+VFL_TYPE_GRABBER/dev/video{n}
Video capture devices and also -- counter-intuitively for the name --
hardware video playback devices such as MPEG2 cards.
-VFL_TYPE_VBI<>/dev/vbi{n}<>
+VFL_TYPE_VBI/dev/vbi{n}
The VBI devices capture the hidden lines on a television picture
that carry further information like closed caption data, teletext
(primarily in Europe) and now Intercast and the ATVEC internet
television encodings.
-VFL_TYPE_VTX<>/dev/vtx[n}<>
+VFL_TYPE_VTX/dev/vtx[n}
VTX is 'Videotext' also known as 'Teletext'. This is a system for
sending numbered, 40x25, mostly textual page images over the hidden
lines. Unlike the /dev/vbi interfaces, this is for 'smart' decoder
@@ -302,25 +302,25 @@
-name<>The device text name. This is intended for the user.
+nameThe device text name. This is intended for the user.
-channels<>The number of different channels you can tune on
+channelsThe number of different channels you can tune on
this card. It could even by zero for a card that has
no tuning capability. For our simple FM radio it is 1.
An AM/FM radio would report 2.
-audios<>The number of audio inputs on this device. For our
+audiosThe number of audio inputs on this device. For our
radio there is only one audio input.
-minwidth,minheight<>The smallest size the card is capable of
capturing
+minwidth,minheightThe smallest size the card is capable of
+capturing
images in. We set these to zero. Radios do not
capture pictures
-maxwidth,maxheight<>The largest image size the card is capable of
+maxwidth,maxheightThe largest image size the card is capable
+of
capturing. For our radio we report 0.
-type<>This reports the capabilities of the device, and
+typeThis reports the capabilities of the device, and
matches the field we filled in in the struct
video_device when registering.
@@ -415,7 +415,7 @@
VIDEO_TUNER_SECAMA SECAM (French) TV tuner
-VIDEO_TUNER_LOW<>
+VIDEO_TUNER_LOW
The tuner frequency is scaled in 1/16th of a KHz
steps. If not it is in 1/16th of a MHz steps
@@ -432,13 +432,13 @@
-VIDEO_MODE_PAL<>PAL Format
+VIDEO_MODE_PALPAL Format
-VIDEO_MODE_NTSC<>NTSC Format (USA)
+VIDEO_MODE_NTSCNTSC Format (USA)
-VIDEO_MODE_SECAM<>French Format
+VIDEO_MODE_SECAMFrench Format
-VIDEO_MODE_AUTO<>A device that does not need to do
+
[RFC] Page LRU State as Scalar
This patch combines the three lru state bits in page->flags into a single scalar field of two bits. In this case, setting the scalar value never costs more than setting a single bit does because each change of state goes through an intermediate step of clearing the state bits to zero, so a single or instruction suffices. There is in fact a slight improvement in efficiency because switch statements can be substituted for chained conditionals, and if there is room for more if gcc is improved to generate better code for switches (it overlooks the fact that the switch expression is two bits wide and generates a redundant test). Testing the state costs an extra masking instruction, but this is done only on debug paths. The long series of debug checks in free_pages_ok is shortened by two. All in all, this should be a wash in terms of efficiency. The state is always tested and set under protection of the pagemap_lru_lock, so there should not be any new races. The motivation for this patch is to provide some infrastructure for memory management experiments using more than three lru lists, along the lines of what we have been discussing recently in the VM Requirement Document thread. To apply: cd /your/2.4.6-sourcetree patch . */ - /* bits 21-29 unused */ + /* bits 6, 7, 11 and 21-29 unused */ +#define PG_state_shift 14 +#define PG_state_mask (3 << PG_state_shift) #define PG_arch_1 30 #define PG_reserved31 @@ -344,17 +343,24 @@ #define PageTestandClearSwapCache(page)test_and_clear_bit(PG_swap_cache, &(page)->flags) -#define PageActive(page) test_bit(PG_active, &(page)->flags) -#define SetPageActive(page)set_bit(PG_active, &(page)->flags) -#define ClearPageActive(page) clear_bit(PG_active, &(page)->flags) - -#define PageInactiveDirty(page)test_bit(PG_inactive_dirty, &(page)->flags) -#define SetPageInactiveDirty(page) set_bit(PG_inactive_dirty, &(page)->flags) -#define ClearPageInactiveDirty(page) clear_bit(PG_inactive_dirty, &(page)->flags) - -#define PageInactiveClean(page)test_bit(PG_inactive_clean, &(page)->flags) -#define SetPageInactiveClean(page) set_bit(PG_inactive_clean, &(page)->flags) -#define ClearPageInactiveClean(page) clear_bit(PG_inactive_clean, &(page)->flags) +#define PG_Nolist 0 +#define PG_Active 1 +#define PG_InactiveClean 2 +#define PG_InactiveDirty 3 + +#define PageNolist(page) (((page)->flags & PG_state_mask) == PG_Nolist << +PG_state_shift) +#define PageActive(page) (((page)->flags & PG_state_mask) == PG_Active << +PG_state_shift) +#define PageInactiveClean(page)(((page)->flags & PG_state_mask) == +PG_InactiveClean << PG_state_shift) +#define PageInactiveDirty(page)(((page)->flags & PG_state_mask) == +PG_InactiveDirty << PG_state_shift) + +#define SetPageNolist(page) ((page)->flags &= ~PG_state_mask) +#define SetPageActive(page) ((page)->flags |= PG_Active << PG_state_shift) +#define SetPageInactiveClean(page) ((page)->flags |= PG_InactiveClean << +PG_state_shift) +#define SetPageInactiveDirty(page) ((page)->flags |= PG_InactiveDirty << +PG_state_shift) + +#define ClearPageActive SetPageNolist +#define ClearPageInactiveClean SetPageNolist +#define ClearPageInactiveDirty SetPageNolist #ifdef CONFIG_HIGHMEM #define PageHighMem(page) test_bit(PG_highmem, &(page)->flags) --- ../uml.2.4.6.clean/include/linux/swap.h Wed Jul 4 00:42:55 2001 +++ ./include/linux/swap.h Fri Jul 6 17:26:39 2001 @@ -182,8 +182,7 @@ * with the pagemap_lru_lock held! */ #define DEBUG_ADD_PAGE \ - if (PageActive(page) || PageInactiveDirty(page) || \ - PageInactiveClean(page)) BUG(); + if (!PageNolist(page)) BUG(); #define ZERO_PAGE_BUG \ if (page_count(page) == 0) BUG(); --- ../uml.2.4.6.clean/mm/page_alloc.c Sat Jun 30 00:39:41 2001 +++ ./mm/page_alloc.c Fri Jul 6 17:25:41 2001 @@ -81,11 +81,7 @@ BUG(); if (PageDecrAfter(page)) BUG(); - if (PageActive(page)) - BUG(); - if (PageInactiveDirty(page)) - BUG(); - if (PageInactiveClean(page)) + if (!PageNolist(page)) BUG(); page->flags &= ~((1> PG_state_shift) + { + case PG_InactiveDirty: del_page_from_inactive_dirty_list(page); add_page_to_active_list(page); - } else if (PageInactiveClean(page)) { + break; + case PG_InactiveClean: del_page_from_inactive_clean_list(page); add_page_to_active_list(page); - } else { + break; + default: /* * The page was not on any list, so we take care * not to do anything. @@ -248,16 +252,21 @@ */ void
Re: [Acpi] Re: ACPI fundamental locking problems
On Friday 06 July 2001 13:16, Alan Cox wrote: > > I am convinced. I misunderstood, thinking there was a big change just > > for > > ACPI which I and many others don't use. Thanks for clearing things up. > > It solves a few long standing arguments too - we can slap .config in it > ending the long standing /proc/config argument without using any ram except > when people care The same for System.map -- 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: Why Plan 9 C compilers don't have asm("")
>Cort Dougan writes: > > I'm talking about _modern_ processors, not processors that dominate >the > > modern age. This isn't x86. > >Linus mentioned Alpha specifically. I don't see how any of the things >he said were x86-centric in any way shape or form. > >All of his examples are entirely accurate on sparc64 for example, and >to even moreso his Alpha commentary can nearly directly be applied to >the MIPS. > >Calls suck ass, even on modern cpus. I've seen several hundreds of > Modern? How many stacks? There's a couple of Forth engines out there that pay the usual for a call and get returns in zero time. Forth code, and Forth engine machine instructions, have about twice as many calls as Linux code, proportionately. Therefor, a return on some designs is one bit in every instruction. Every instruction is "...and maybe do a return in parallel." Forth engines don't have caches. They have on-chip stacks, or the Novix has separate busses to the stacks. Both stacks, return and data. Forth chips aren't modern in the true-multi-user sense, but if an individual were to design such a beast they could get several of them, hundreds maybe, on FPGAs available now. Such things are coming, because a Forth chip IS something an individual can design. Rick Hohensee www.clienux.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/
New Machine Check problem
Hello, Have a system with an Asus P5A motherboard, Classic Pentium-200 underclocked to 180 MHz, and 196 MB of real memory. Up through 2.4.4 it has performed flawlessly. Kernels 2.4.5 and 2.4.6 will not complete the boot. Boot looks normal through the F0 0F check, and the message about "Intel old style machine check architecture supported.". It then spews a semi-infinite stream of: "CPU#0: Machine Check Exception: 0x 10C1D0 (type 0x 9)." lines (until at least the reset button is pressed. I caught this by setting up for serial console at 300bps, which slowed the screen enough to make notes by hand. This new check in bluesmoke.c is causing severe indigestion to a formerly reliable system. Suggestions appreciated, and glad to run any tests, but will be leaving Monday Jul. 9 for 2 weeks away from computers. Bill Earnestwde@fast-dot-netLinux PoweredAllentown, PA, USA Computers, like air conditioners, work poorly with Windows open. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems halting/rebooting with 2.4.{5,6}-ac
Jordan Breeding wrote: > > Jordan Breeding wrote: > > > > I have a Tyan Tiger 230 SMP system running dual 1 GHz PIII processors. > > The processors are of the same lot and revision, bought on the same > > day. Everything worked fine or some time in regard to > > halting/rebooting. I was using ac kernels configured with ACPI. At the > > time of the merge with the Linus stuff which included new ACPI I started > > configuring with ACPI and ACPI bus management and I could no longer halt > > the system but rebooting worked OK. As of 2.4.5-ac24 and 2.4.6-ac1 I > > can no longer halt or reboot my system properly using no power > > management or ACPI, and APM still displays the message about being > > broken on SMP. Has anyone seen this problem, is there a fix for it? > > Another thing I have noticed is that my /proc/cpuinfo file looks like > > this: > > > > processor : 0 > > vendor_id : GenuineIntel > > cpu family : 6 > > model : 8 > > model name : Pentium III (Coppermine) > > stepping: 6 > > cpu MHz : 999.694 > > cache size : 256 KB > > fdiv_bug: no > > hlt_bug : no > > f00f_bug: no > > coma_bug: no > > fpu : yes > > fpu_exception : yes > > cpuid level : 2 > > wp : yes > > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge > > mca cmov pat pse36 mmx fxsr sse > > bogomips: 1992.29 > > > > processor : 1 > > vendor_id : GenuineIntel > > cpu family : 6 > > model : 8 > > model name : Pentium III (Coppermine) > > stepping: 6 > > cpu MHz : 999.694 > > cache size : 256 KB > > fdiv_bug: no > > hlt_bug : no > > f00f_bug: no > > coma_bug: no > > fpu : yes > > fpu_exception : yes > > cpuid level : 3 > > wp : yes > > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge > > mca cmov pat pse36 mmx fxsr sse > > bogomips: 1998.84 > > > > Notice the difference in cpuid level and bogomips values between the > > two. These processors should be exactly the same, same lot and revision > > and everything else according to the shrink wrapped Intel retail boxes > > they came out of. What could be casuing them to show up at different > > cpuid levels? Thanks for any help with either issue. > > > > Jordan Breeding > > Very sorry to have not included more information, when halting or > rebooting it now stop at INIT: there are no more processes left at this > run level and never actually reboots or halts. To get around it I > either have to hit the power/reset buton or use SysReq to reboot it. > Thanks again for any help. > > Jordan Breeding Okay, I did some more testing. I tried doing a reverse patch using Intels ACPI patch from 2.4.5-pre3 to the current ACPI version. So now I was running 2.4.6-ac1 with the old ACPI. The same thing happened. So then I started thinking about anything else I had possibly changed around the same time frame as the ACPI version change. I had changed from the normal UHCI to the Alternate (JE) UHCI drvier to allow me to use a USB Sun keyboard and mouse successfully on an SMP kernel. So the next time that I tried a halt/reboot and it hung I tried showing the task list using SysRq and khubd goes into zombie state when shutting down. Anyone have any ideas why? Everything else left still running (all kernel threads) was just in sleep state. I assume this is a big part of my problem. Thanks in advance. Jordan Breeding - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DMA memory limitation?
> > > GFP_DMA is ISA dma reachable, Forget the IA64, their setup is weird and > > > should best be ignored until 2.5 as and when they sort it out. > > Really ? I don't think I can ignore IA64, there are people who ask for it Well the current IA64 tree isnt related to the standard Linux behaviour so you need to take that up with the IA64 people. Obviously their non standard behaviour causes problems. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: are ioctl calls supposed to take this long?
"Richard B. Johnson" wrote: > > On Fri, 6 Jul 2001, Chris Friesen wrote: > > Are you sure about this? In the tulip.c driver the following appears to be the > > salient code: >. This falls through to > SIOCDEVPRIVATE+1 Doh! Okay, I need caffeine, or sugar, or something... Sorry about that. Chris -- Chris Friesen| MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada| email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PROBLEM: linux 2.4.6 SMP+i810_audio = oops
hi, i get an oops w/ linux 2.4.x, SMP and i810_audio. any suggestions? details: [1.] One line summary of the problem: linux 2.4.6 SMP+i810_audio = oops [2.] Full description of the problem/report: play an mp3 - get an oops. if not the first time then the second. the oops comes at the end of the song (maybe when /dev/audio is closed or some clean-up occurs?) this only happens with an SMP kernel. the only differences in my config files are: 61,62c61,62 < CONFIG_SMP=y < CONFIG_HAVE_DEC_LOCK=y --- > # CONFIG_SMP is not set > # CONFIG_X86_UP_IOAPIC is not set 69,70d68 < CONFIG_X86_IO_APIC=y < CONFIG_X86_LOCAL_APIC=y audio is on-board i810_audio i took the time to check all versions and use egcs this time w/ 2.4.6, but i've seen the same behavior w/ all the 2.4.x kernels i've run - some from kernel.org and the two from redhat. [3.] Keywords (i.e., modules, networking, kernel): sound symmetric multi-processing oops i810_audio [4.] Kernel version (from /proc/version): see [5.] [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) (i have 3 more of these if anyone wants them under slightly different compiler or kernels and i can make more... ) Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) ksymoops 2.4.0 on i686 2.4.6-2. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.6-2/ (default) -m /boot/System.map-2.4.6-2 (default) [snip] Unable to handle kernel NULL pointer dereference at virtual address 0104 printing eip: c8918d63 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: c3541f50 ebx: c06cccf0 ecx: edx: c3541c00 esi: c060 edi: dc80 ebp: esp: c6605e90 ds: 0018 es: 0018 ss: 0018 Process esd (pid: 1571. stackpage=c6605000) Stack: c3541c00 0040 c3541c00 0011 c3541f50 c6604000 c8918e6b c3541c00 c26bfa80 0401 c0108486 0011 c3541c00 c6605f0c 0220 c026ea20 0011 c6605f04 c0108679 0011 c6605f0c c26bfa80 Call Trace: [] [] [] [] [] [] [] Code: 03 b9 04 01 00 00 89 7c 24 18 83 c7 06 66 89 7c 24 16 89 fa >>EIP; c8918d63<= Trace; c0108486 Trace; c0108679 Trace; c0106da4 Trace; c0134065 Trace; c0132f30 Trace; c0132f97 Trace; c0106d1b Code; c8918d63 <_EIP>: Code; c8918d63<= 0: 03 b9 04 01 00 00 add0x104(%ecx),%edi <= Code; c8918d69 6: 89 7c 24 18 mov%edi,0x18(%esp,1) Code; c8918d6d a: 83 c7 06 add$0x6,%edi Code; c8918d70 d: 66 89 7c 24 16mov%di,0x16(%esp,1) Code; c8918d75 12: 89 fa mov%edi,%edx Kernel panic: Aiee, killing interrupt handler! 1 warning issued. Results may not be reliable. [6.] A small shell script or example program which triggers the problem (if possible) mpg123 13\ The\ Flag.mp3 (not specific to bare naked ladies, happens with other groups too...;) [7.] Environment Dell Precision 220 Dual PIII Redhat 7.1 free -m total used free sharedbuffers cached Mem: 123107 16 0 2 56 -/+ buffers/cache: 47 76 Swap: 517 0517 [7.1.] Software (add the output of the ver_linux script here) Linux clapper.digitalpulp.com 2.4.6 #2 Thu Jul 5 13:20:26 EDT 2001 i686 unknown Gnu C 2.96 Gnu make 3.79.1 binutils 2.10.91.0.2 util-linux 2.10s mount 2.11b modutils 2.4.6 e2fsprogs 1.19 Linux C Library2.2.2 Dynamic linker (ldd) 2.2.2 Procps 2.0.7 Net-tools 1.57 Console-tools 0.3.3 Sh-utils 2.0 Modules Loaded nfsd lockd sunrpc 3c59x ipt_REJECT ipt_LOG ipt_limit ipt_state iptable_filter ip_conntrack_ftp ip_conntrack ip_tables nls_iso8859-1 isofs loop (i actually used CC=egcs egcs -v gives: Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) ) [7.2.] Processor information (from /proc/cpuinfo): processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 6 cpu MHz : 797.975 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1592.52 (above in uniprocessor mode) [7.3.] Module information (from /proc/modules):
Re: are ioctl calls supposed to take this long?
On Fri, 6 Jul 2001, Chris Friesen wrote:
> "Richard B. Johnson" wrote:
> >
> > On Fri, 6 Jul 2001, Chris Friesen wrote:
> >
> > > I am using the following snippet of code to find out some information about the
> > > MII PHY interface of my ethernet device (which uses the tulip driver). When I
> > > did some timing measurements with gettimeofday() I found that the ioctl call
> > > takes a bit over a millisecond to complete. This seems to me to be an awfully
> > > long time for what should be (as far as I can see) a very simple operation.
>
> > It's not ioctl() overhead, it's what has to be done in the driver to
> > get the information you request.
> >
> > (1) Stop the chip
> > (2) Read the media interface using an awful SERIAL protocol in which
> > you manipulate 3 bits using multiple instructions, to send
> > or receive a single BIT (not BYTE) of data. You do the 8 times
> > per byte.
> > (3) Restart the chip.
>
> Are you sure about this? In the tulip.c driver the following appears to be the
> salient code:
>
> static int private_ioctl(struct device *dev, struct ifreq *rq, int cmd)
> {
> struct tulip_private *tp = (struct tulip_private *)dev->priv;
> long ioaddr = dev->base_addr;
> u16 *data = (u16 *)>ifr_data;
> int phy = tp->phys[0] & 0x1f;
> long flags;
>
> switch(cmd) {
> case SIOCDEVPRIVATE:/* Get the address of the PHY in use. */
> if (tp->mii_cnt)
> data[0] = phy;
> else if (tp->flags & HAS_NWAY143)
> data[0] = 32;
> else if (tp->chip_id == COMET)
> data[0] = 1;
> else
> return -ENODEV;
>
. This falls through to
SIOCDEVPRIVATE+1
>
> I don't see any device stopping or reading of the media interface here. Now
> there may be something very subtle hidden somewhere that I'm not seeing, but
> this looks like some relatively straightforward comparisons.
Look at tulip_mdio_read() and the zillions of times it's called.
It's called in SIOCDEVPRIVATE+1 when SIOCDEVPRIVATE falls through.
It falls through always, unless there is the -ENODEV error.
tulip_mdio_read() does the bit-banging junk.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ext3-2.4-0.9.0
An update of the ext3 journalling filesystem for 2.4 kernels is available at http://www.uow.edu.au/~andrewm/linux/ext3/ Patches are against 2.4.6-ac1 and 2.4.6. Changes since 0.0.8 include: - Multiplied the version numbering by ten to cater for bugfix releases against the 0.9.0 stream. - The main thrust has been the removal of a number of changes in the core kernel which were required for to support the journalling of data. This has caused some duplication of core code within ext3, but it's not too bad. - A number of cleanups and resyncs with latest ext2. (Thanks, Al). - Reorganised and optimised ext3_write_inode() and the handling of files which were opened O_SYNC. - Move quota operations outside lock_super() - fixes last known source of quota deadlocks in -ac kernels. - Deleted large chunks of debug/development support code. - Improved handling of corner-case errors. - Improved robustness in out-of-memory situations. The last change is probably the most significant - it prevents possible crashes and fs corruption under extreme workloads. - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DMA memory limitation?
> > GFP_DMA is ISA dma reachable, Forget the IA64, their setup is weird and > > should best be ignored until 2.5 as and when they sort it out. Really ? I don't think I can ignore IA64, there are people who ask for it > > > bounce buffers are needed. On Alpha GFP_DMA is not limited at all (I think). >Correct me if > > > > Alpha has various IOMMU facilities > > > > > I'm wrong, but I really think there should be a general way of allocating memory >that is > > > 32bit addressable (something like GFP_32BIT?) so you don't need a lot of >#ifdef's in your > > > code. > > No ifdefs are needed > > > > GFP_DMA - ISA dma reachable > > pci_alloc_* and friends - PCI usable memory > > pci_alloc_* is designed to support ISA. > > Pass pci_dev==NULL to pci_alloc_* for ISA devices, and it allocs GFP_DMA > for you. > Sure, but the IA64 platforms that are out now doesn't have an IOMMU, so bounce buffers are used if you don't specify GFP_DMA in your get_free_page. Now lets say you have a driver with a page allocator. Eventually you want to make some if the allocated pages available to a 32bit PCI device. These pages has to be consistent (i.e the driver doesn't have to wait for a PCI flush for the data to be valid, sort of like a ethernet ring buffer). I could use the pci_alloc_consistent() function (pci_alloc_consistent() allocates a buffer with GFP_DMA on IA64), but since I already have the pages, I have to use pci_map_single (or pci_map_sg). Inside pci_map_single on IA64 something called swiotlb buffers (bounce buffers) are used if the device can't support 64bit addressing and the address of the memory to map is above the 4G limit. The swiotlb buffers are below the 4G limit and therefore reachable by any PCI device. The problem about these buffers are that the content are not copied to the original location before you do a pci_sync_* or a pci_unmap_* (they are not consistent) and they are a limited resource (allocated at boot time). My solution for now was to use : #if defined(__ia64__) int flag = GFP_DMA; #else int flag = 0; #endif Maybe IA64 could implement GFP_HIGHMEM (as on i386) so that if no flags were used you were guaranteed to get 32bit memory ??? Regards -- Steffen Persvold Systems Engineer Email : mailto:[EMAIL PROTECTED] Scali AS (http://www.scali.com) Tlf : (+47) 22 62 89 50 Olaf Helsets vei 6 Fax : (+47) 22 62 89 51 N-0621 Oslo, Norway - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
