* Re: Support for Arctic platform (405LP based)
From: Tom Rini @ 2002-12-16 15:04 UTC (permalink / raw)
To: Cort Dougan; +Cc: Paul Mackerras, linuxppc-embedded
In-Reply-To: <20021215174120.E30568@duath.fsmlabs.com>
On Sun, Dec 15, 2002 at 05:41:20PM -0700, Cort Dougan wrote:
> } 4xx in particular is a problem because I'm not convinced about the
> } approach that has been taken for some of the 4xx infrastructure. The
> } ocp stuff seems a lot more complicated than it needs to be, for
> } instance. There is no particular reason that I can see why the 8xx
> } stuff in 2_4_devel shouldn't go to Marcelo for 2.4.21.
>
> How about a linuxppc_2_4 that is a child of Marcelo's. Then a
> linuxppc_2_4_4xx (and what have you) that is a child of the linuxppc_2_4
> tree? It would make integration much much easier. Right now the
> diff between _2_4 and _2_4_devel seems to be non-monotonically increasing.
> I think it would be hard to arrest that growth without switching to a
> Macelo based tree.
I'm not sure how that would stop the growth of the '_devel' tree, it
would just split it up into 4xx, and everything else. And my goal of
the new few weeks is to try and move everything that's not 4xx that I
can get my hands on to test into the _2_4 tree. I'm not sure just how
much of that I'll actually be able to do, but I'm going to try.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: /proc/cpuinfo and hyperthreading
From: Måns Rullgård @ 2002-12-16 15:11 UTC (permalink / raw)
To: Scott Robert Ladd; +Cc: root, Brian Jackson, Linux Kernel Mailing List
In-Reply-To: <FKEAJLBKJCGBDJJIPJLJIELIDLAA.scott@coyotegulch.com>
"Scott Robert Ladd" <scott@coyotegulch.com> writes:
> > How do you know this? How can I learn what Windows does with
> > Win/2000/professional?
>
> Run the Windows Task Manager and selected the Performance tab; on my system,
> it shows two separate graphs, one for each logical CPU.
It's easy to write a program that displays any number of graphs
vaguely related to the system load. How do we know that the
performance meter isn't lying?
--
Måns Rullgård
mru@users.sf.net
^ permalink raw reply
* Re: Support for Arctic platform (405LP based)
From: Tom Rini @ 2002-12-16 15:02 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Cort Dougan, linuxppc-embedded
In-Reply-To: <15869.5023.549830.146265@argo.ozlabs.ibm.com>
On Mon, Dec 16, 2002 at 10:43:27AM +1100, Paul Mackerras wrote:
> Cort Dougan writes:
>
> > How about killing the _2_4_devel tree? When I created it I want it to be a
> > playground for stabilizing then moving things over to 2_4 failry quickly.
> > It seems to have become the defacto "want board X, you better use
> > _2_4_devel" tree.
>
> Now that Marcelo is using BK, what I would really like to do is to
> kill both the linuxppc_2_4 and linuxppc_2_4_devel trees and move to a
> tree that is a child of Marcelo's linux-2.4 tree.
... but old history? :)
[snip]
> ... There is no particular reason that I can see why the 8xx
> stuff in 2_4_devel shouldn't go to Marcelo for 2.4.21.
I'll try and get to that too, once finals are over :)
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Arctic-2 MTD driver
From: Tom Rini @ 2002-12-16 15:01 UTC (permalink / raw)
To: Marius Groeger; +Cc: David Gibson, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.40.0212160945060.1222-100000@mag.devdep.sysgo.de>
On Mon, Dec 16, 2002 at 09:46:50AM +0100, Marius Groeger wrote:
>
> Hello David,
>
> On Mon, 16 Dec 2002, David Gibson wrote:
>
> > Having committed the core support code for the Arctic-2, here come
> > some drivers for it. Below is an MTD map for the Arctic-2, derived
> > from beech-mtd.c. Essentially all it does is provide suitable
> > hardwired partitions.
>
> Can you also post this to the linux-mtd folks?
No point in doing that yet, as the underlying support code for the
Arctic-2 won't be making Marcelo's tree for a while yet.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* alsasound init script (Re: possible problems with rc6 aplay )
From: Takashi Iwai @ 2002-12-16 14:53 UTC (permalink / raw)
To: Paul Davis; +Cc: Mark Knecht, martin-langer, Alsa-Devel, swpatrick
In-Reply-To: <E18NwBf-0003qc-00@sc8-sf-list1.sourceforge.net>
At Mon, 16 Dec 2002 09:29:05 -0500,
Paul Davis wrote:
>
> >the standard alsasound init script can call a card-dependent script
>
> that reminds me. the last version of the alsasound script that i saw
> did something very dangerous. it seemed to try to install *every*
> snd-card module it could find. if you have a system with an ISA bus,
> this can prove fatal to the system - many ISA device probes will kill
> the machine if the device is not present.
well, you can find that the alsasound script tries to load the modules
aliased as "snd-card-[0-9]", not the all snd-card-* modules.
remember that there is no module named as such. that means, if such a
module is found, it was certainly configured by some means.
ciao,
Takashi
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: possible problems with rc6 aplay
From: Paul Davis @ 2002-12-16 14:51 UTC (permalink / raw)
To: martin-langer; +Cc: Mark Knecht, alsa-devel, swpatrick, tiwai
In-Reply-To: <20021216143611.GN773@tuba.home>
>IMHO this is a design bug of all rme cards. The documents about rme32 and
>rme96 where identical in this point. They were talking about one master-mode
>and nothing about the frequency. I don't know anything about rme9652 or
>hdsp, but the sourcecode looks not very different to the older rme96.
>
>But if you read the datasheet from prodif24 (not supported by alsa) you have
>a switch with one slave position and three frequency positions. After
the problem here is not setting the card to master mode and not having
a defined frequency - this doesn't happen because there is a defined
default rate (just not well documented). the problem is setting the
rate and it appearing to succeed, even though in fact it has made no
difference to the operation of the card because its slaved to some
external clock.
>Alsa has copied here the documented rme way, but this seems to be wrong for
>me. I have just checked the behaviour of rme32, but I'm very sure that the
>bigger ones are working in the same style.
well, they have a more complex setup:
* clock mode: AutoSync, Master or Word Clock
* preferred source for autosync: ADAT1/2/3 or S/PDIF
* S/PDIF sample rate
* ADAT sample rate
* system sample rate (the one the master clock runs at)
so its really not possible to define "the rate" in a straightforward
way. but i see your point.
--p
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: mmap() and NFS server performance
From: Trond Myklebust @ 2002-12-16 14:50 UTC (permalink / raw)
To: Matthew Mitchell; +Cc: nfs
In-Reply-To: <3DFDE455.1000004@geodev.com>
>>>>> " " == Matthew Mitchell <matthew@geodev.com> writes:
> 1) What would you like to see, tcpdump/snoop wise, to verify
> this?
nfsstat on the client should normally tell you how often you are
seeing RPC retransmits.
> 2) Could UDP service really be causing this order of magnitude
> slowdown?
Certainly: retransmissions follow an *exponential* backoff rule. For
that reason, it doesn't take a very high percentage of retransmissions
before you see a large impact.
> 3) Is TCP server code "ready enough" for production use? In
> our case we
> don't mind some occasional bugs, but it needs to be able to
> stay working under reasonable load for a day or so at a time
> for us to get anything done ("Stale NFS file handle" is a
> scourge...).
That is more of a question for Neil Brown, but I personally don't have
any particularly bad experiences to report.
Cheers,
Trond
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: Updated Release
From: Stephen D. Smalley @ 2002-12-16 14:57 UTC (permalink / raw)
To: selinux, hdholm
The updated release (2002121210) has been imported and merged into
the sourceforge selinux CVS tree under the 'nsa' module. As usual,
you can check out a copy via:
cvs -d:pserver:anonymous@cvs.selinux.sourceforge.net:/cvsroot/selinux \
-z3 co nsa
On Fri, 12 Dec 2002, Howard Holm wrote:
> The SELinux web site <http://www.nsa.gov/selinux/> including the mail
> list archive has been updated. The site includes a new release of the
> LSM-based SELinux prototype. The base kernel versions have been updated
> to 2.4.20 and 2.5.51. Initial SID and context for SCMP packets has been
> added. Additional policy enhancement and patch contributions have been
> merged. The logrotate patch has been updated to 3.6.5-2. The private
> file oversight in LSM, inode_doinit bug in SELinux, and selopt compile
> problems have all been fixed.
--
Stephen Smalley, NSA
sds@epoch.ncsc.mil
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re[2]: [Oops 2.5.51] PnPBIOS: cat /proc/bus/pnp/escd
From: Ruslan U. Zakirov @ 2002-12-16 14:57 UTC (permalink / raw)
To: Dave Jones; +Cc: linux-kernel
In-Reply-To: <20021216135813.GD11616@suse.de>
DJ> > 'cat /proc/bus/pnp/escd' consistantly produces this:
DJ> > EIP: 0088:[<00007b74>] Not tainted
DJ> You blew up in BIOS code. Your BIOS has a crap PNPBIOS implementation.
DJ> Send the output of dmidecode[1] and it can get added to the blacklist.
DJ> [1] http://people.redhat.com/arjanv/dmidecode.c
DJ> Dave
Have we got any chance to solve this problem with BIOS update?
Here is results of DMI decode:
SMBIOS 2.3 present.
DMI 2.3 present.
29 structures occupying 978 bytes.
DMI table at 0x000F04F0.
Handle 0x0000
DMI type 0, 20 bytes.
BIOS Information Block
Vendor: American Megatrends Inc.
Version: 62710
Release: 06/01/2000
BIOS base: 0xF0000
ROM size: 192K
Capabilities:
Flags: 0x000000007FCBDE90
Handle 0x0001
DMI type 1, 25 bytes.
System Information Block
Vendor: Gigabyte Technology Co.
Product: 7IXE4
Version: 0000000
Serial Number: 00000000
Handle 0x0002
DMI type 2, 8 bytes.
Board Information Block
Vendor: Gigabyte Technology Co., Ltd.
Product: 7IXE4
Version: 1.1
Serial Number: 00000000
Handle 0x0003
DMI type 3, 17 bytes.
Chassis Information Block
Vendor:
Chassis Type: Desktop
Version: 1.0
Serial Number: 0000000
Asset Tag:
Handle 0x0004
DMI type 4, 32 bytes.
Processor
Socket Designation: Socket-A
Processor Type: Central Processor
Processor Family: K5
Processor Manufacturer: AMD
Processor Version: Duron(tm)
Handle 0x0005
DMI type 7, 19 bytes.
Cache
Socket: Internal
L1 Internal Cache: write-back
L1 Cache Size: 128K
L1 Cache Maximum: 128K
L1 Cache Type: Synchronous
Handle 0x0006
DMI type 7, 19 bytes.
Cache
Socket: Internal
L2 Internal Cache: disabled
L2 Cache Size: 512K
L2 Cache Maximum: 64K
L2 Cache Type: Synchronous
Handle 0x0007
DMI type 5, 22 bytes.
Memory Controller
Handle 0x0008
DMI type 6, 12 bytes.
Memory Bank
Socket: DIMM3
Banks: 0 1
Type: UNKNOWN
Installed Size: Not Installed
Enabled Size: Not Installed
Handle 0x0009
DMI type 6, 12 bytes.
Memory Bank
Socket: DIMM2
Banks: 2 3
Type: UNKNOWN
Installed Size: Not Installed
Enabled Size: Not Installed
Handle 0x000A
DMI type 6, 12 bytes.
Memory Bank
Socket: DIMM1
Banks: 4 5
Speed: 15nS
Type: DIMM SDRAM
Installed Size: 64Mbyte
Enabled Size: 64Mbyte
Handle 0x000B
DMI type 9, 13 bytes.
Card Slot
Slot: PCI1
Type: 32bit PCI
Status: In use.
Slot Features: 3.3v Shared
Handle 0x000C
DMI type 9, 13 bytes.
Card Slot
Slot: PCI2
Type: 32bit PCI
Status: Available.
Slot Features: 3.3v Shared
Handle 0x000D
DMI type 9, 13 bytes.
Card Slot
Slot: PCI3
Type: 32bit PCI
Status: Available.
Slot Features: 3.3v Shared
Handle 0x000E
DMI type 9, 13 bytes.
Card Slot
Slot: PCI4
Type: 32bit PCI
Status: In use.
Slot Features: 3.3v Shared
Handle 0x000F
DMI type 9, 13 bytes.
Card Slot
Slot: PCI5
Type: 32bit PCI
Status: Available.
Slot Features: 3.3v Shared
Handle 0x0010
DMI type 9, 13 bytes.
Card Slot
Slot: ISA1
Type: 16bit ISA
Slot Features: 3.3v Shared
Handle 0x0011
DMI type 9, 13 bytes.
Card Slot
Slot: ISA2
Type: 16bit ISA
Slot Features: 3.3v Shared
Handle 0x0012
DMI type 9, 13 bytes.
Card Slot
Slot: AGP
Type: 32bit AGP 4x
Slot Features: 3.3v Shared
Handle 0x0013
DMI type 8, 9 bytes.
Port Connector
Internal Designator: COM Port
Internal Connector Type: None
External Designator: Serial Port A
External Connector Type: DB-9 pin male
Port Type: Serial Port 16650A Compatible
Handle 0x0014
DMI type 8, 9 bytes.
Port Connector
Internal Designator: COM Port
Internal Connector Type: None
External Designator: Serial Port B
External Connector Type: DB-9 pin male
Port Type: Serial Port 16650A Compatible
Handle 0x0015
DMI type 8, 9 bytes.
Port Connector
Internal Designator: LPT Port
Internal Connector Type: None
External Designator: Parallel Port
External Connector Type: DB-25 pin female
Port Type: Parallel Port ECP/EPP
Handle 0x0016
DMI type 8, 9 bytes.
Port Connector
Internal Designator: Keyboard
Internal Connector Type: None
External Designator: Keyboard
External Connector Type: PS/2
Port Type: Keyboard Port
Handle 0x0017
DMI type 8, 9 bytes.
Port Connector
Internal Designator: Mouse
Internal Connector Type: None
External Designator: PS/2 Mouse
External Connector Type: PS/2
Port Type: Mouse Port
Handle 0x0018
DMI type 8, 9 bytes.
Port Connector
Internal Designator: Floppy
Internal Connector Type: On Board Floppy
External Designator: Floppy
External Connector Type: None
Port Type: None
Handle 0x0019
DMI type 8, 9 bytes.
Port Connector
Internal Designator: Primary IDE
Internal Connector Type: On Board IDE
External Designator: IDE-1
External Connector Type: None
Port Type: None
Handle 0x001A
DMI type 8, 9 bytes.
Port Connector
Internal Designator: Secondary IDE
Internal Connector Type: On Board IDE
External Designator: IDE-2
External Connector Type: None
Port Type: None
Handle 0x001B
DMI type 8, 9 bytes.
Port Connector
Internal Designator: USB Port
Internal Connector Type: None
External Designator: USB
External Connector Type: Access Bus (USB)
Port Type: USB
Handle 0x001C
DMI type 13, 22 bytes.
BIOS Language Information
Best regards.
Ruslan.
^ permalink raw reply
* RE: /proc/cpuinfo and hyperthreading
From: Scott Robert Ladd @ 2002-12-16 14:56 UTC (permalink / raw)
To: root, Brian Jackson; +Cc: Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.3.95.1021216090324.20273A-100000@chaos.analogic.com>
Richard Johnson asked:
> How do you know this? How can I learn what Windows does with
> Win/2000/professional?
Run the Windows Task Manager and selected the Performance tab; on my system,
it shows two separate graphs, one for each logical CPU.
> if two CPUs are present...." Direct quote. If you have two logical
> CPUs, you can't remove one, therefore, unless M$ has fixed the problem(s)
> in XP, you can't use Windows with two logical CPUs, i.e., hyperthreading.
The machine came with Windows XP pre-installed; I ran it a couple of times,
then blew it away (do I hear cheers?) when I installed Linux. I probably
didn't run it long-enough to hit any bugs.
..Scott
--
Scott Robert Ladd
Coyote Gulch Productions, http://www.coyotegulch.com
No ads -- just very free (and somewhat unusual) code.
^ permalink raw reply
* Re: 2.5.5[01]]: Xircom Cardbus broken (PCI resource collisions)
From: Valdis.Kletnieks @ 2002-12-16 14:54 UTC (permalink / raw)
To: ALESSANDRO.SUARDI; +Cc: zwane, davej, pekon, linux-kernel
In-Reply-To: <336830.1039886899684.JavaMail.nobody@web11.us.oracle.com>
[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]
On Sat, 14 Dec 2002 09:28:19 PST, "ALESSANDRO.SUARDI" said:
> > On Fri, 13 Dec 2002 Valdis.Kletnieks@vt.edu wrote:
> > > On Fri, 13 Dec 2002 17:36:56 GMT, Dave Jones said:
> > >
> > > > It's my understanding that pci_enable_device() *must* be called
> > > > before we fiddle with dev->resource, dev->irq and the like.
> > >
> > > OK.. it looks like the problem only hits if it's a PCMCIA card *with an
> > > onboard ROM*.
> > Hmm i just saw this thread, which card is the non working one?;
>
> It's a RBEM56G-100.
>
> Sorry it took me a while to reply - Valdis' patch does fix the problem for
> me, too. Awaiting for a final form of the fix in the upcoming series :)
Same here. I was getting bit on a Xircom card:
03:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03)
03:00.1 Serial controller: Xircom Cardbus Ethernet + 56k Modem (rev 03)
Dave has a point about not poking IRQ's before it's initialized, so I think
I'll let him and Alan discuss the *right* way to fix it. (Though if there's
need to test a patch more elegant/correct than mine, I'm more than happy to
do so...)
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: [PATCH] envy24control.[ch] update for hoontech cards.
From: Takashi Iwai @ 2002-12-16 14:44 UTC (permalink / raw)
To: Jaroslav Kysela; +Cc: Henry Walpool, Claus R, alsa-devel@lists.sourceforge.net
In-Reply-To: <Pine.LNX.4.33.0212161517540.503-100000@pnote.perex-int.cz>
At Mon, 16 Dec 2002 15:25:26 +0100 (CET),
Jaroslav wrote:
>
> On Sun, 15 Dec 2002, Henry Walpool wrote:
>
> > The Hoontech Media 7.1 card has a consumer/professional option at least
> > under windows. I would assume that with the correct information from
> > hoontech one could program this under alsa. Of course I don't have a
> > clue, I'm just guessing here.
>
> It's possible that newer cards can drive this control via GPIO, but I have
> no information about the Media 7.1 version.
Perhaps Claus knows the details according to Henry's post a few weeks
ago...
Takashi
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: Arctic-2 MTD driver
From: Tom Rini @ 2002-12-16 14:43 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20021216020922.GH4981@zax.zax>
On Mon, Dec 16, 2002 at 01:09:22PM +1100, David Gibson wrote:
> Having committed the core support code for the Arctic-2, here come
> some drivers for it. Below is an MTD map for the Arctic-2, derived
> from beech-mtd.c. Essentially all it does is provide suitable
> hardwired partitions.
>
> Again, any comments before I commit this?
Only that it reminded me that drivers/mtd/maps/Config.in needs some
cleanups for PPC32, I'll be commiting those momentarily. But other than
that, it looks fine.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [parisc-linux] problems with PCI IDE controller
From: John David Anglin @ 2002-12-16 13:57 UTC (permalink / raw)
To: John Marvin; +Cc: parisc-linux
In-Reply-To: <200212160609.XAA18500@udlkern.fc.hp.com>
> > On Sat, 2002-12-14 at 13:10, Matthew Wilcox wrote:
> > > > hp-c240 login: Uniform Multi-Platform E-IDE driver Revision: 6.31
> > > > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> > > > PDC20268: IDE controller on PCI bus 00 dev 08
> > > > PDC20268: chipset revision 2
> > > > PDC20268: not 100% native mode: will probe irqs later
See the same on the pc that I have.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply
* RE: Is the preemptive kernel patch unsafe for 8xx/PPC?
From: acurtis @ 2002-12-16 14:41 UTC (permalink / raw)
To: joakim.tjernlund, Eugene Surovegin; +Cc: linuxppc-dev, acurtis
In-Reply-To: <IGEFJKJNHJDCBKALBJLLMEMJFIAA.joakim.tjernlund@lumentis.se>
I ran this patch on 2.4.19 and here were my results.
> > 1) arch/ppc/kernel.entry.S
> >
> > diff -urN linux-2.4.20/arch/ppc/kernel/entry.S
> linux/arch/ppc/kernel/entry.S
> > --- linux-2.4.20/arch/ppc/kernel/entry.S 2002-11-28
> > 18:53:11.000000000 -0500
> > +++ linux/arch/ppc/kernel/entry.S 2002-12-11
> 02:34:47.000000000 -0500
> > @@ -278,6 +278,41 @@
> > */
> > cmpi 0,r3,0
> > beq restore
> > +#ifdef CONFIG_PREEMPT
> > + lwz r3,PREEMPT_COUNT(r2)
> > + cmpi 0,r3,1
> > + bge ret_from_except
> > + lwz r5,_MSR(r1)
> > + andi. r5,r5,MSR_PR
> > + bne do_signal_ret
> >
> > <rest of the diff is skipped>
> >
> > I had to change the last command to "bne ret_from_except".
> > I checked MontaVista tree, and they have "ret_from_except" there also.
>
> This I can not comment on, but my 8xx runs fine with it.
I did not make the above code change and it appears to run. Any comments?
> > 2) include/asm-ppc/pgalloc.h There are curly brackets missing in
> > get_pgd_fast()
>
> Yes, they are missing in the else part.
I had to fix this too.
> > 3) to support 440GP you have to modify
> arc/ppc/kernel/irc.c:preempt_intercept:
> >
> > #if !defined(CONFIG_4xx) || defined(CONFIG_440)
> > case 0x900:
> > #else
> > case 0x1000:
> > #endif
I could not test these changes either. Any feedback from Robert Love?
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* RE: roxio easy cd creator 5 and linux
From: Chen, Jyh-Shing @ 2002-12-16 14:41 UTC (permalink / raw)
To: 'dashielljt'; +Cc: linux-admin
Hi Jude,
Traditionally, the Slackware installation organized the software into
different type of disks (A, AP, D, ..., X, etc.) that one would put
on floppies for installation. Even though the installation is now
mostly using CD directly, I guess the tradition of using disks to
group applications still lives on.
On Slackware 8.0 CD, there is the slakware directory. The binaries for
the various disks that you can install are organized into various
folders using names similar to the ones mentioned above. The CD-R tools
is located under ap1 directory and is called cdrtools.tgz.
The easiest way to install that tool is probably to copy that file from
CD to /tmp and run pkgtool to install it. Alternatively, you can use
the setup program and pick out ONLY the AP disks and use expert mode
to pick just the cdrtools package for installation.
You could run "which mkisofs" and "which cdrecord" to see if it is
installed on your system.
Jyh-shing
-----Original Message-----
From: dashielljt [mailto:dashielljt@gmpexpress.net]
Sent: Friday, December 13, 2002 8:20 PM
To: Chen, Jyh-Shing
Cc: linux-admin@vger.kernel.org
Subject: RE: roxio easy cd creator 5 and linux
Thanks, is the ap disks a link on the slackware site? I did a full
install of slackware and so far haven't found cdrtools on this computer.
Jude <dashielljt(at)gmpexpress-dot-net>
On Fri, 13 Dec 2002, Chen, Jyh-Shing wrote:
Hi,
On slackware 8.0, there is cdrtools under the AP disks.
If you install that tool and make sure that the ide-scsi module
is either running or already compiled into the kernel, then you
should be able to use mkisofs to make ISO image and use cdrecord
to burn a CD for most IDE writers. I have used those tools for
some time now on a few IDE writers.
Jyh-shing
-----Original Message-----
From: dashielljt [mailto:dashielljt@gmpexpress.net]
Sent: Thursday, December 12, 2002 9:42 PM
To: linux-admin@vger.kernel.org
Subject: roxio easy cd creator 5 and linux
I have one of these cdrw drives and it's an ide connect nd it reads no
problem but doing the cd-writing howto that brand and model isn't listed
in my version of the howto file (need to update my howtos), and the script
to make devices and scan cdrw drives also fails to work. I'm wondering if
roxio has a driver on line that needs downloading. I haven't had a chance
to get sighted assistance reading the manuals for it yet since there's so
much junk mail tossed in my mailbox daily. If someone here has their
drive burning using linux I'd like to know I'm not alone out here. The
box had as one of its hardware requirements slackware 3.5 and I have
slackware 8.0 runnning over here so figured it should be possible to get
fully functional.
Jude <dashielljt(at)gmpexpress-dot-net>
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: mmap() and NFS server performance
From: Matthew Mitchell @ 2002-12-16 14:33 UTC (permalink / raw)
To: Trond Myklebust; +Cc: nfs
In-Reply-To: <shsadj826bt.fsf@charged.uio.no>
Trond Myklebust wrote:
>>>>>>" " == Matthew Mitchell <matthew@geodev.com> writes:
>>>>>
>
> > values. These apps were originally written on Solaris with
> > Solaris NFS servers assumed to be the data source; the Sun guys
> > said that mmap would be much faster than read/write and they
> > were correct. However, now that we have a few Linux NFS
> > servers, we're seeing the opposite.
>
> As long as the clients are still Solaris, then the only difference can
> be the network, and the server performance.
>
> Of the 2, the bigger 'generic' troublemaker tends to be the network.
> Solaris clients always tend to prefer NFS over TCP since that tends to
> be more reliable on poor networks than does UDP. Unfortunately, NFS
> over TCP on the server side is a fairly recent addition to Linux: it
> only just made it into the stable release 2 weeks ago (when 2.4.20 was
> released). To the best of my knowledge, none of the RedHat kernels
> support it yet.
For some reason it had not occurred to me that the NFS server on the
Linux box might be using UDP instead of TCP; I had it in my head somehow
that it would use TCP. Obviously it wasn't. Now, we had noticed slower
speeds with UDP before (when Linux clients were using UDP to access the
Solaris servers). Could this be causing such a drastic slowdown?
I have looked at some network packet streams and I don't think we are
having any of the classic UDP problems -- negligible # of retransmits,
most packets arrive in order. The Linux server isn't loaded hardly at all.
Three further questions:
1) What would you like to see, tcpdump/snoop wise, to verify this?
2) Could UDP service really be causing this order of magnitude slowdown?
3) Is TCP server code "ready enough" for production use? In our case we
don't mind some occasional bugs, but it needs to be able to stay working
under reasonable load for a day or so at a time for us to get anything
done ("Stale NFS file handle" is a scourge...).
Thanks again.
--
Matthew Mitchell
Systems Programmer/Administrator matthew@geodev.com
Geophysical Development Corporation phone 713 782 1234
1 Riverway Suite 2100, Houston, TX 77056 fax 713 782 1829
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: NFS oopses on smp servers
From: Bernhard Kaindl @ 2002-12-16 14:38 UTC (permalink / raw)
To: Peter Lojkin; +Cc: nfs, Chris Mason
In-Reply-To: <E18NaDc-000MXq-00@f20.mail.ru>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 5512 bytes --]
On Sun, 15 Dec 2002, Peter Lojkin wrote:
> we keep getting nfs related oopses on our servers. we tried stock
[Trace reformatted for better reading:]
> EIP: 0010:[nfs_release_request+137/180]
> [nfs_try_to_free_pages+268/288]
> [nfs_create_request+168/288]
> [nfs_update_request+544/828]
> [nfs_updatepage+165/516]
> [nfs_commit_write+63/108]
> Code: 8b 00 85 c0 7d 08 0f 0b a9 00 52 0c 2a c0 53 e8 0b ff ff ff
Hi,
we've nailed an identical looking oops which we were able to reproduce
also with a 8-CPU Machine running the NFS-Client under extreme load, it
happened also with 2.4.20-NFS-ALL without any other patch in addition.
Chris Mason found the cause for this oops, I've attached his patch with
enhanced description from me. I've only tested the other, smaller diff
extensively(2nd, smaller attachment), but the patch from Chris should
be ok as well.
Configuration:
NFS client: Dell PowerEdge 6650, eight(8) 1.6GHz Xeon Processors, 4GB RAM
NFS server: Network Appliance NetApp F825(Storage Appliance, high-perf)
Network: Direct crossover 1000Mbit Ethernet without switch using Fiber.
With this configuration I was able to trigger within one hour after starting
an extreme load test reaching a load of >45 on the NFS-Client only doing
NFS Work(setting up ~1GB chroot environments and compiling in them, many
many in parallel)
Problem description:
The problem is that nfs_clear_request and nfs_release_request
contain accesses to the file's inode which are done after the
fput of the file which could have freed the inode also.
In extreme circumstances the inode pointer used for these accesses
could point to reused/cleared memory which would lead to an oops.
Fix discussion:
The idea of the fix is to not to fput the file until the request
is completely gone.
The fput needs to be done after the the last access to the inode
because the fput could free the inode also.
There are two different ways to do it, one would be to change
nfs_clear_request to not do an fput at all, and do the fput in
nfs_release_request.
But since nfs_release_request calls nfs_clear_request, it looks
like nfs_clear_request wasn't intended to be called separately
at a few places before nfs_release_request is called.
So the calls to nfs_clear_request before nfs_release_request
should be removed, nfs_release_request calls nfs_clear_request
itself at the right time after the last cleanup and the consisteny
checks.
To achieve this completely, nfs_clear_request must be also
reordered to do the fput last since the unpatched code accesses
the inode after the fput which can also lead to an oops on SMP
under extreme conditions.
Patch Description:
------------------
Remove the calls to nfs_clear_request before nfs_release_request,
to avoid freeing the file in nfs_clear_request because this could
also free the inode which is then accessed in nfs_release_request
directly afterwards.
Also reorder nfs_clear_request to do the fput last, since
the unpatched code accesses the inode after the fput.
This patch also changes nfs_clear_request to static and removes
the extern declaration, because it's not called from outside of
pagelist.o anymore after the diff applied.
Possible Improvement after applying the patch:
----------------------------------------------
In a second step, the code from nfs_clear_request could
be moved to nfs_release_request to reduce code size and
number of instructions since nfs_release_request should
be the only caller of nfs_clear_request then.
Best Regards,
Bernhard Kaindl
UnitedLinux Development
SuSE Linux - www.suse.com
PS: Other sample traces from this test/oops (different kernels)
>>EIP; c0197001 <nfs_release_request+101/130> <=====
Trace; c0197616 <nfs_try_to_free_pages+36/240>
Trace; c0196e21 <nfs_create_request+b1/120>
Trace; c019b006 <nfs_update_request+126/490>
Trace; c019b3cc <nfs_strategy+5c/70>
Trace; c019b578 <nfs_updatepage+c8/2c0>
Trace; c0192c72 <nfs_commit_write+72/d0>
Trace; c013cf15 <generic_file_write+495/800>
Trace; c0192dc8 <nfs_file_write+98/100>
Trace; c014da67 <sys_write+97/1d0>
Trace; c010984f <system_call+33/38>
>>EIP; c01a48ce <nfs_release_request+8e/c0> <=====
Trace; c01a4ef6 <nfs_try_to_free_pages+36/150>
Trace; c02613cc <skb_copy_datagram_iovec+4c/280>
Trace; c01a4768 <nfs_create_request+a8/110>
Trace; c025f0f6 <__kfree_skb+106/170>
Trace; c01a85d1 <nfs_update_request+c1/350>
Trace; c01a8a3e <nfs_updatepage+9e/270>
Trace; c0143067 <do_generic_file_write+447/7e0>
Trace; c025b098 <sock_recvmsg+58/f0>
Trace; c014349b <generic_file_write+9b/d0>
Trace; c01a0aab <nfs_file_write+bb/140>
Trace; c0154c47 <sys_write+97/140>
Trace; c01095ef <system_call+33/38>
Code; c01a48ce <nfs_release_request+8e/c0>
00000000 <_EIP>:
Code; c01a48ce <nfs_release_request+8e/c0> <=====
0: 8b 00 mov (%eax),%eax <=====
Code; c01a48d0 <nfs_release_request+90/c0>
2: 85 c0 test %eax,%eax
Code; c01a48d2 <nfs_release_request+92/c0>
4: 78 1e js 24 <_EIP+0x24> c01a48f2 <nfs_release_r
equest+b2/c0>
Code; c01a48d4 <nfs_release_request+94/c0>
6: 89 1c 24 mov %ebx,(%esp,1)
Code; c01a48d7 <nfs_release_request+97/c0>
9: e8 f4 fe ff ff call ffffff02 <_EIP+0xffffff02> c01a47d0 <n
fs_clear_request+0/70>
Code; c01a48dc <nfs_release_request+9c/c0>
e: a1 04 15 42 c0 mov 0xc0421504,%eax
Code; c01a48e1 <nfs_release_request+a1/c0>
13: 89 00 mov %eax,(%eax)
[-- Attachment #2: Type: TEXT/PLAIN, Size: 4416 bytes --]
Patch and original short Description from Chris Mason,
Description extended by Bernhard Kaindl, both SuSE.
Symptom:
--------
Oopses in nfs_clear_request and nfs_release_request(NFS-Client)
under extreme Circumstances on SMP-Machines(happened with 4 CPUs)
Problem:
--------
nfs_clear_request and nfs_release_request contain accesses
to the file's inode which are done after the fput of the
file which could have freed the inode also.
In extreme circumstances the inode pointer used for these accesses
could point to reused/cleared memory which would lead to an oops.
Solution:
---------
The idea of the fix is to not to fput the file until the request
is completely gone.
The fput needs to be done after the the last access to the inode
because the fput could free the inode also.
There are two different ways to do it, one would be to change
nfs_clear_request to not do an fput at all, and do the fput in
nfs_release_request.
But since nfs_release_request calls nfs_clear_request, it looks
like nfs_clear_request wasn't intended to be called separately
at a few places before nfs_release_request is called.
So the calls to nfs_clear_request before nfs_release_request
should be removed, nfs_release_request calls nfs_clear_request
itself at the right time after the last cleanup and the consisteny
checks.
To achieve this completely, nfs_clear_request must be also
reordered to do the fput last since the unpatched code accesses
the inode after the fput which can also lead to an oops on SMP
under extreme conditions.
Patch Description:
------------------
Remove the calls to nfs_clear_request before nfs_release_request,
to avoid freeing the file in nfs_clear_request because this could
also free the inode which is then accessed in nfs_release_request
directly afterwards.
Also reorder nfs_clear_request to do the fput last, since
the unpatched code accesses the inode after the fput.
This patch also changes nfs_clear_request to static and removes
the extern declaration, because it's not called from outside of
pagelist.o anymore after the diff applied.
Possible Improvement after applying this patch:
------------------------------------------------
In a second step, the code from nfs_clear_request could
be moved to nfs_release_request to reduce code size and
number of instructions since nfs_release_request should
be the only caller of nfs_clear_request then.
--- linux-2.4.19.SuSE/fs/nfs/pagelist.c
+++ linux-2.4.19.SuSE/fs/nfs/pagelist.c
@@ -122,13 +122,8 @@
* Release all resources associated with a write request after it
* has completed.
*/
-void nfs_clear_request(struct nfs_page *req)
+static void nfs_clear_request(struct nfs_page *req)
{
- /* Release struct file or cached credential */
- if (req->wb_file) {
- fput(req->wb_file);
- req->wb_file = NULL;
- }
if (req->wb_cred) {
put_rpccred(req->wb_cred);
req->wb_cred = NULL;
@@ -138,6 +133,13 @@
req->wb_page = NULL;
atomic_dec(&NFS_REQUESTLIST(req->wb_inode)->nr_requests);
}
+ /* Release struct file or cached credential, do it last since it
+ * can iput
+ */
+ if (req->wb_file) {
+ fput(req->wb_file);
+ req->wb_file = NULL;
+ }
}
--- linux-2.4.19.SuSE/fs/nfs/read.c
+++ linux-2.4.19.SuSE/fs/nfs/read.c
@@ -222,7 +222,6 @@
nfs_list_remove_request(req);
SetPageError(page);
UnlockPage(page);
- nfs_clear_request(req);
nfs_release_request(req);
nfs_unlock_request(req);
}
@@ -428,7 +427,6 @@
(long long)NFS_FILEID(req->wb_inode),
req->wb_bytes,
(long long)(page_offset(page) + req->wb_offset));
- nfs_clear_request(req);
nfs_release_request(req);
nfs_unlock_request(req);
}
--- linux-2.4.19.SuSE/fs/nfs/write.c
+++ linux-2.4.19.SuSE/fs/nfs/write.c
@@ -338,7 +338,6 @@
iput(inode);
} else
spin_unlock(&nfs_wreq_lock);
- nfs_clear_request(req);
nfs_release_request(req);
}
--- linux-2.4.19.SuSE/include/linux/nfs_page.h
+++ linux-2.4.19.SuSE/include/linux/nfs_page.h
@@ -44,7 +44,6 @@
extern struct nfs_page *nfs_create_request(struct rpc_cred *, struct inode *,
struct page *,
unsigned int, unsigned int);
-extern void nfs_clear_request(struct nfs_page *req);
extern void nfs_release_request(struct nfs_page *req);
[-- Attachment #3: Type: TEXT/PLAIN, Size: 2392 bytes --]
# Note, this is the minimum diff which I(bk) tested extensivly
# on zert185 with the Network Appliance NetApp185 as NFS-Server.
Symptom:
--------
Oopses in nfs_clear_request and nfs_release_request(NFS-Client)
under extreme Circumstances on SMP-Machines(happened with 4 CPUs)
Problem:
--------
nfs_clear_request and nfs_release_request contain accesses
to the file's inode which are done after the fput of the
file which could free the inode also.
Solution / Patch Description:
-----------------------------
Remove the calls to nfs_clear_request before nfs_release_request,
to avoid freeing the file in nfs_clear_request because this could
also free the inode which is then accessed in nfs_release_request
directly afterwards.
Also reorder nfs_clear_request to do the fput last, since
the unpatched code accesses the inode after the fput.
Side Notes:
-----------
Patch for nfs_clear_request from Chris Mason, full patch from Chris did
also remove nfs_clear_request from a few places, this patch only
removes the remaining inode debug-paranoia check from nfs_release_request
which would have also been done after the fput.
This is the minimum Patch, the original fix+cleanup from Chris Mason also
removed the call of nfs_clear_request before nfs_release_request, in
some places which means that the nfs_clear_request call inside
nfs_release_request becomes the 'hot' call to nfs_clear_request
and nfs_clear_request can then also be integrated into nfs_release_request
since this should be the only place where nfs_clear_request is called then.
--- l/fs/nfs/pagelist.c
+++ l/fs/nfs/pagelist.c
@@ -124,11 +124,6 @@
*/
void nfs_clear_request(struct nfs_page *req)
{
- /* Release struct file or cached credential */
- if (req->wb_file) {
- fput(req->wb_file);
- req->wb_file = NULL;
- }
if (req->wb_cred) {
put_rpccred(req->wb_cred);
req->wb_cred = NULL;
@@ -138,6 +133,11 @@
req->wb_page = NULL;
atomic_dec(&NFS_REQUESTLIST(req->wb_inode)->nr_requests);
}
+ /* release file last since it can iput */
+ if (req->wb_file) {
+ fput(req->wb_file);
+ req->wb_file = NULL;
+ }
}
@@ -165,8 +165,6 @@
BUG();
if (NFS_WBACK_BUSY(req))
BUG();
- if (atomic_read(&NFS_REQUESTLIST(req->wb_inode)->nr_requests) < 0)
- BUG();
#endif
/* Release struct file or cached credential */
^ permalink raw reply
* Re: possible problems with rc6 aplay
From: Martin Langer @ 2002-12-16 14:36 UTC (permalink / raw)
To: Mark Knecht; +Cc: paul, alsa-devel, swpatrick, tiwai
In-Reply-To: <1040040264.1358.8.camel@Godzilla>
On Mon, Dec 16, 2002 at 04:04:23AM -0800, Mark Knecht wrote:
>
> I'm having an interesting problem with this setup with now that's
> probably based in this area. If I bring up these two systems with the
> main DAW in Linux, and the slave system in Windows everything is fine.
> The DAW controls the frequency via my running jack, but even at first
> boot the two sides lock together just fine.
>
> If I then boot the DAW into Windows, the two sides start making noise
> through the speakers, and if I look at the RME app in Windows on the
> slave machine, the frequency is bouncing around and so is the mode
> saying it's master or slave. The worst part is I get ugly noise out of
> my speakers unless I tell one f the two Windows machines what mode to be
> in.
>
> On Mon, 2002-12-16 at 02:17, Martin Langer wrote:
> >
> > But using master clock mode without defining a frequency before isn't
> > plausible for me and defining one master mode for each frequency was only a
> > quick solution by me.
> >
IMHO this is a design bug of all rme cards. The documents about rme32 and
rme96 where identical in this point. They were talking about one master-mode
and nothing about the frequency. I don't know anything about rme9652 or
hdsp, but the sourcecode looks not very different to the older rme96.
But if you read the datasheet from prodif24 (not supported by alsa) you have
a switch with one slave position and three frequency positions. After
changing my driver from the rme way to this prodif24 way it runs without
this strange frequency problems some people have (I remember
vanDongen/Gilcher talking about a similar problem with his 96/8).
Alsa has copied here the documented rme way, but this seems to be wrong for
me. I have just checked the behaviour of rme32, but I'm very sure that the
bigger ones are working in the same style.
BTW: prodif24 document is on ftp.alsa-project.org
martin
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: [PATCH] Add CONFIG_ACPI_RELAXED_AML option
From: NoZizzing OrDripping @ 2002-12-16 14:34 UTC (permalink / raw)
To: Pavel Machek, Moore, Robert
Cc: 'Herbert Nachtnebel', NoZizzing OrDripping,
acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Therien, Guy,
Grover, Andrew
In-Reply-To: <20021215205944.GA6330-I/5MKhXcvmPrBKCeMvbIDA@public.gmane.org>
--- Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org> wrote:
> Hi!
> > What is really being proposed here is for Linux
> ACPI to be bug-for-bug
> > compatible with Microsoft. This is impossible to
> do deterministically
> > because the MS interpreter is closed source. The
> only standard that we have
> > that we can code to is the ACPI specification, and
> this has to be the last
> > word on the matter.
>
> Okay, but we can try. We can for example ignore
> '*PNP101' and
> understand it as 'PNP101', with printk("Star is not
> valid character in
> device name"), which is way more helpufull than
> /proc/battery does not
> exist.
>
> I believe CONFIG_ACPI_RELAXED_AML is good idea.
> Pavel
The opinions on this are going to break down along the
lines of who has working AML, and who doesn't, with
the tie-breaker going to the distro that wants to
have as many satisfied "customers" as possible. Right
now, that distro is XP :-(
Anyway, I did a tightened up CONFIG_RELAXED_AML_PATCH
that restricts the slopiness along the lines that Alan
suggested, and also outputs a one-time warning for
any region access violation.
However, a more general implementation would provide
either a global nagged_already bit, or better yet
a per-object nagged_already bit. Or for the most
pedantic, per-object and per-violation-type
nagged_already bits.
Its nasty ugliness, no doubt, but I think that while
strict conformance to standards is a lofty goal, a
loftier goal is for mere mortals to be able to
install Linux on the most popular laptops.
BTW, Best Buy had the Toshiba Satellite 1115-S103 on
sale for only $500 USD yesterday (after $600 in
rebates and markdowns!). The new bar has been set,
and these
sub-$1000 laptops with buggy AML are going to continue
to profilerate.
If we could agree to add the mechanism, then people
could contribute additional workarounds. It would
still be a controllable feature, turned on only if
desired.
-Rick
rickr-EySxSuIQeMUAvxtiuMwx3w@public.gmane.org
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: Dual Xeon w/ HT: Kernel can't find second CPU
From: Patrick R. McManus @ 2002-12-16 14:42 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20021212162914.E28629@deltelco.com>
> > Sent: Friday, December 06, 2002 6:57 PM
> > To: linux-kernel@vger.kernel.org
> > Subject: Re: Dual Xeon w/ HT: Kernel can't find second CPU
I have a similar (but different) problem that I was hoping for help
with.
I can't build a kernel for my dual xeon e7500 board, with
hyperthreading enabled, that sees 4 logical processors. I can boot the
redhat 8 kernel and that sees 4, but my build of 2.4.20-ac2 gets me
'warning sibling not found' messages and just 2 cpus.
It is built for P4 and has SMP on. Is there anything else I should
have to do? acpismp=force doesn't help (not that it should on 2.4.20
from what I read.)
[..]
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
Intel machine check reporting enabled on CPU#0.
CPU: After generic, caps: 3febfbff 00000000 00000000 00000000
CPU: Common caps: 3febfbff 00000000 00000000 00000000
CPU0: Intel(R) XEON(TM) CPU 2.40GHz stepping 04
per-CPU timeslice cutoff: 1462.99 usecs.
task migration cache decay timeout: 10 msecs.
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Booting processor 1/2 eip 2000
Initializing CPU#1
masked ExtINT on CPU#1
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Calibrating delay loop... 4797.23 BogoMIPS
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 3
Intel machine check reporting enabled on CPU#1.
CPU: After generic, caps: 3febfbff 00000000 00000000 00000000
CPU: Common caps: 3febfbff 00000000 00000000 00000000
CPU1: Intel(R) XEON(TM) CPU 2.40GHz stepping 04
Total of 2 processors activated (9581.36 BogoMIPS).
WARNING: No sibling found for CPU 0.
WARNING: No sibling found for CPU 1.
[...]
-Patrick
^ permalink raw reply
* Re: Discovery II (was Re: Support for Arctic platform (405LP based))
From: Mark A. Greer @ 2002-12-16 14:33 UTC (permalink / raw)
To: Roland Dreier; +Cc: linuxppc-embedded
In-Reply-To: <52fzsxpww2.fsf@topspin.com>
Roland Dreier wrote:
> Thanks... my next question is where is the linux-galileo tree? (I'm
>sure this is well-known to people working with Discovery II but please
>forgive my ignorance as I'm just starting to look at this platform)
>
>
No problem, I should have included that. These should get you started...
http://source.mvista.com/pipermail/linux-galileo/2002-January/000002.html
http://source.mvista.com/
and, IIRC for anon bk:
bk clone bk://source.mvista.com/linuxppc_2_4_galileo
Mark
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: rmap and nvidia?
From: O.Sezer @ 2002-12-16 14:25 UTC (permalink / raw)
To: linux-kernel
The 2.5 patches at http://www.minion.de/nvidia.html
may give some clue. They use pte_offset_map , yes,
but no corresponding pte_unmap ...
^ permalink raw reply
* Re: possible problems with rc6 aplay
From: Paul Davis @ 2002-12-16 14:29 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Mark Knecht, martin-langer, Alsa-Devel, swpatrick
In-Reply-To: <s5h4r9et6au.wl@alsa2.suse.de>
>the standard alsasound init script can call a card-dependent script
that reminds me. the last version of the alsasound script that i saw
did something very dangerous. it seemed to try to install *every*
snd-card module it could find. if you have a system with an ISA bus,
this can prove fatal to the system - many ISA device probes will kill
the machine if the device is not present.
the alsasound script should assume, i think, that alsaconf has been
run, and that only modules listed in /etc/modules.conf or its
equivalent should be loaded.
--p
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* RE: /proc/cpuinfo and hyperthreading
From: Scott Robert Ladd @ 2002-12-16 14:36 UTC (permalink / raw)
To: Dave Jones; +Cc: Linux Kernel Mailing List
In-Reply-To: <20021216140809.GE11616@suse.de>
Dave Jones wrote:
> Looks like you're either missing some ACPI config options, or
> you haven't updated the BIOS yet. On 2.5.51 with latest BIOS on
> the same box, I get..
Everything is fixed. No, I hadn't upgraded the BIOS; when I asked a contact
at Intel about the problem, I was told told me that BIOS was the latest.
I should have know better than to believe them!
Thank you very much; cat /proc/cpuinfo now reports two CPUs.
..Scott
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.