* Problems with running BP 7.0 and a application made with BP
From: Karlheinz Blau @ 2002-12-18 18:10 UTC (permalink / raw)
To: linux-msdos
Hello together,
I tried to start a application on a SuSE 8.1 system.
DOSEMU built-in command.com version 1.0
DOSEMU version is 1.0.2.0, 2001/06/10
FreeDOS kernel version 1.1.24 [Jun 10 2001 22:25:01]
XX-DOS version reported is 5.0
This is my DOSEMU
As we programmed our SYbon with BP 7.0 in 1994 we started it with a former
DOSEMU. So I know, that is could work - but how.
Is there anybody with some help for me?
Thanks al lot
Karlheinz Blau
^ permalink raw reply
* Re: 2.4.19, don't "hdparm -I /dev/hde" if hde is on a Asus A7V133 Promise ctrlr, or...
From: Ross Biro @ 2002-12-18 18:17 UTC (permalink / raw)
To: D.A.M. Revok; +Cc: linux-kernel
In-Reply-To: <200212151549.37661.marvin@synapse.net>
There is a bug in the Promise driver that clears an important PIO bit
when switching into DMA mode. When you do an hdparm -I, it issues a
drive command that attempts to transfer data in PIO mode, but since the
PIO mode timing registers are hosed, the machine locks up. It's easy to
reproduce and applies to all drive commands that return data including
SMART commands.
The bit in particular is bit 4 of PCI config register 0x61+4*channel
number (PB bit 4 in Promise terms.) I've got a very unclean fix that I
will attempt to clean up once I can put a few more important issues to bed.
For the time being, you can try to do a work around by putting the drive
into PIO mode with hdparm -X 12 before issuing any drive commands.
Ross
D.A.M. Revok wrote:
>( that's a capital-aye in the hdparm line )
>
>not even the Magic SysReq key will work.
>
>also, don't
>
>"cd /proc/ide/hde ; cat identify"
>
>... same thing
>drive-light comes on, but have to use the power-switch to get the machine
>back, ( lost stuff again, fuck )
>
>
>proc says it's pdc202xx
>
>Promise Ultra series driver Ver 1.20.0.7 2002-05-23
>Adapter: Ultra100 on M/B
>
>
>
^ permalink raw reply
* [PATCH] arch/ia64 update
From: Bjorn Helgaas @ 2002-12-18 18:16 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-kernel
Hi Marcelo,
Please do a
bk pull http://lia64.bkbits.net/to-marcelo-2.4
This will update the following files:
arch/ia64/hp/sim/simeth.c | 533 ---------------
arch/ia64/hp/sim/simscsi.c | 384 -----------
arch/ia64/hp/sim/simscsi.h | 39 -
arch/ia64/hp/sim/simserial.c | 1095 --------------------------------
include/asm-ia64/offsets.h | 142 ----
arch/ia64/boot/bootloader.c | 10
arch/ia64/config.in | 12
arch/ia64/defconfig | 76 --
arch/ia64/hp/common/sba_iommu.c | 229 ++++--
arch/ia64/hp/sim/Makefile | 10
arch/ia64/hp/sim/simeth.c | 535 +++++++++++++++
arch/ia64/hp/sim/simscsi.c | 384 +++++++++++
arch/ia64/hp/sim/simscsi.h | 39 +
arch/ia64/hp/sim/simserial.c | 1097 ++++++++++++++++++++++++++++++++
arch/ia64/hp/zx1/hpzx1_misc.c | 514 +++++++--------
arch/ia64/ia32/ia32_signal.c | 415 +++++++++++-
arch/ia64/ia32/sys_ia32.c | 173 +++--
arch/ia64/kernel/acpi.c | 99 +-
arch/ia64/kernel/efi.c | 240 ++++---
arch/ia64/kernel/entry.S | 26
arch/ia64/kernel/fw-emu.c | 80 +-
arch/ia64/kernel/gate.S | 65 +
arch/ia64/kernel/head.S | 485 +++++++-------
arch/ia64/kernel/ia64_ksyms.c | 14
arch/ia64/kernel/iosapic.c | 4
arch/ia64/kernel/irq.c | 2
arch/ia64/kernel/irq_ia64.c | 2
arch/ia64/kernel/machvec.c | 2
arch/ia64/kernel/mca.c | 149 +++-
arch/ia64/kernel/pal.S | 46 +
arch/ia64/kernel/pci.c | 53 +
arch/ia64/kernel/perfmon.c | 1213 +++++++++++++++++++-----------------
arch/ia64/kernel/perfmon_generic.h | 71 +-
arch/ia64/kernel/perfmon_itanium.h | 89 +-
arch/ia64/kernel/perfmon_mckinley.h | 121 ++-
arch/ia64/kernel/process.c | 4
arch/ia64/kernel/ptrace.c | 83 ++
arch/ia64/kernel/signal.c | 47 +
arch/ia64/kernel/smp.c | 16
arch/ia64/kernel/smpboot.c | 4
arch/ia64/kernel/sys_ia64.c | 23
arch/ia64/kernel/traps.c | 3
arch/ia64/kernel/unaligned.c | 95 +-
arch/ia64/lib/Makefile | 2
arch/ia64/lib/carta_random.S | 54 +
arch/ia64/lib/memcpy_mck.S | 27
arch/ia64/lib/swiotlb.c | 47 -
arch/ia64/mm/Makefile | 2
arch/ia64/mm/fault.c | 4
arch/ia64/mm/init.c | 132 ++-
arch/ia64/mm/tlb.c | 4
arch/ia64/sn/io/pci_dma.c | 64 -
arch/ia64/sn/kernel/setup.c | 2
arch/ia64/vmlinux.lds.S | 2
include/asm-ia64/acpi.h | 12
include/asm-ia64/ia32.h | 74 ++
include/asm-ia64/io.h | 32
include/asm-ia64/machvec.h | 10
include/asm-ia64/machvec_hpzx1.h | 2
include/asm-ia64/machvec_sn1.h | 2
include/asm-ia64/machvec_sn2.h | 2
include/asm-ia64/mc146818rtc.h | 10
include/asm-ia64/mca.h | 2
include/asm-ia64/mca_asm.h | 3
include/asm-ia64/mmu.h | 8
include/asm-ia64/mmu_context.h | 55 +
include/asm-ia64/page.h | 11
include/asm-ia64/pal.h | 43 +
include/asm-ia64/pci.h | 11
include/asm-ia64/perfmon.h | 53 +
include/asm-ia64/pgalloc.h | 45 -
include/asm-ia64/pgtable.h | 20
include/asm-ia64/processor.h | 8
include/asm-ia64/sal.h | 3
include/asm-ia64/scatterlist.h | 3
include/asm-ia64/siginfo.h | 4
include/asm-ia64/system.h | 2
include/asm-ia64/unistd.h | 21
78 files changed, 5271 insertions(+), 4228 deletions(-)
through these ChangeSets:
<bjorn_helgaas@hp.com> (02/12/13 1.757.10.38)
ia64: Alternate signal stack fix. Patch from David Mosberger.
<bjorn_helgaas@hp.com> (02/12/13 1.757.10.37)
ia64: break trap: die_if_kernel only if break value is 0.
(Backport from 2.5 changeset of 02/08/29).
<bjorn_helgaas@hp.com> (02/12/12 1.757.10.36)
ia64: Move simeth, simserial, simscsi back to drivers/ for init ordering.
<bjorn_helgaas@hp.com> (02/12/12 1.757.10.35)
ia64: Update defconfig with 2.4.20 defaults, build in ext3.
<bjorn_helgaas@hp.com> (02/12/10 1.757.10.34)
ia64: Avoid holding task lock while calling access_process_vm().
<bjorn_helgaas@hp.com> (02/12/10 1.757.10.33)
ia64: Avoid holding tasklist_lock across routines that do IPIs (such as flush_tlb_all()).
(From 2.5 patch by David Mosberger).
<bjorn_helgaas@hp.com> (02/12/10 1.757.10.32)
ia64: Fix typo in unaligned memory access handler (no functional change).
<davidm@tiger.hpl.hp.com> (02/12/10 1.757.10.31)
ia64: Fix unaligned memory access handler.
<venkatesh.pallipadi@intel.com> (02/12/03 1.757.10.30)
ia64: IA-32 ptrace: xmm reg support, fpstate 'tag' fix, fp TOS fix
Attached is the patch to IA32 ptrace code in IA64 kernel. This
patch basically helps gdb'ing of an ia32 app (with ia32
gdb binary). The patch can easily be verified by running gdb and
looking at all-registers.
The changes done in the patch include:
1) Support for xmm registers.
At present xmm registers are not saved/restored during
ptrace and gdb wont show them. Patch adds new ptrace
options (IA32_PTRACE_GETFPXREGS and IA32_PTRACE_SETFPXREGS,
used by gdb to get/set fp+xmm state).
2) Bug fix in getting 'tag' field of fpstate
(fsr>>16 in place of fsr>>32)
3) Bug fix in calculating fp TOS
(it is a 3 bit field in fsr. Using (fsr>>11) & 7 in place
of (fsr>>11) & 3)
Also, I had to add new structures in ia32.h, corresponding to
the way gdb is expecting the data. Gdb uses structures
defined in sys/user.h
<davidm@tiger.hpl.hp.com> (02/12/03 1.757.10.29)
ia64: Patch by Venkatesh Pallipadi to fix IA-32 signal handling to restore
instruction and data pointers.
<davidm@tiger.hpl.hp.com> (02/12/03 1.757.10.28)
ia64: Some formatting cleanups.
<venkatesh.pallipadi@intel.com> (02/12/03 1.757.10.27)
[PATCH] ia64: Clearing of exception status before calling IA32 user signal handler
One more bug fix for IA32 exception handler. IA32 exception handler is
not clearing the exception status, before calling the user signal handler
routine.
<venkatesh.pallipadi@intel.com> (02/12/03 1.757.10.26)
[PATCH] ia64: Save/Restore of IA32 fpstate in sigcontext
The IA32 fpstate information is not getting saved/restored during IA32
exception handling. The issue was first observed due to an IA32 binary
(which runs fine on IA32 system), failing on Itanium based system. The
binary was trying to access the fpstate information during an FPE and got a
SEGV, as the fpstate was not getting saved and the sigcontext->fpstate
pointer was NULL.
<eranian@frankl.hpl.hp.com> (02/12/03 1.757.10.25)
ia64: perfmon: This patch adds:
- full support for randomization of sampling periods
- a hook for VTune and possibly Prospect so that they can
synchronize access to the PMU with perfmon
- updates the initialization to reflect what I have in my development
kernel (we do not use PAL anymore).
- update perfmon version to 1.2
This patch fixes:
- the bug your reported about perfmon_init_percpu()
<bjorn_helgaas@hp.com> (02/12/03 1.757.10.24)
ia64: Include vendor/function ID for "Unknown" IOCs.
<bjorn_helgaas@hp.com> (02/12/03 1.757.10.23)
ia64: Fix race between TLB purges and reload_context.
(From David Mosberger)
<alex_williamson@hp.com> (02/12/02 1.757.10.22)
ia64: If no CPE interrupt, poll periodically for CPEs.
<bjorn_helgaas@hp.com> (02/11/19 1.757.10.19)
ia64: Workaround for old toolchain (__get_user() in perfmon).
<eranian@frankl.hpl.hp.com> (02/11/19 1.757.10.18)
ia64: perfmon update.
<jsm@udlkern.fc.hp.com> (02/11/15 1.757.10.16)
ia64: Use virtual mem map automatically if >1GB gap found
Enclosed is a patch for 2.4 that is similar to what is going out with Red
Hat AS for ia64. This makes the virtual mem map support "automatic", i.e.
it will use a virtual mem map if CONFIG_DISCONTIGMEM is not defined and a
gap of greater than 1 GB is found in the physical memory layout.
<bjorn_helgaas@hp.com> (02/11/14 1.757.10.15)
ia64: Make mremap() work properly when returning "negative" addresses.
Based on patch by Matt Chapman, 2.5 fix by David Mosberger.
<davidm@tiger.hpl.hp.com> (02/11/14 1.757.10.14)
ia64: Make it easier to set a breakpoint in the Ski simulator right before
starting the kernel (based on patch by Peter Chubb).
<kenneth.w.chen@intel.com> (02/11/14 1.757.10.13)
ia64: Change memcpy to return dest address.
<bjorn_helgaas@hp.com> (02/11/14 1.757.10.12)
ia64: Fix efi_memmap_walk() to work with more complicated memory maps.
Bug reported by Charles Sluder, 2.5 fix by David Mosberger.
<bjorn_helgaas@hp.com> (02/11/14 1.757.10.11)
ia64: Fix ACPI_ACQUIRE_GLOBAL_LOCK and ACPI_RELEASE_GLOBAL_LOCK.
Bug reported by Charles Sluder, 2.5 fix by David Mosberger.
<jung-ik.lee@intel.com> (02/11/14 1.757.10.10)
[PATCH] ia64: PCI hotplug changes for 2.5.39 or later
The following patch fixes ia64 kernel dump on Hot-Add of PCI bridge cards.
pcibios_fixup_bus();
pci_do_scan_bus();
on Hot-Add of bridge adapter;
(pulled from 2.5 ia64 tree)
<bjorn_helgaas@hp.com> (02/11/14 1.757.10.9)
ia64: Make flush_tlb_mm() work for multi-threaded address-spaces on SMP machines.
(From David Mosberger's 2.5 patch).
<bjorn_helgaas@hp.com> (02/11/14 1.757.10.8)
ia64: Rename __flush_tlb_all() to local_flush_tlb_all().
<jenna.s.hall@intel.com> (02/11/13 1.757.10.7)
ia64: Minor MCA bugfixes.
<bjorn_helgaas@hp.com> (02/11/13 1.757.10.6)
ia64: Restore "fake PCI device" support, for XFree86. This is intended
to go away in 2.5.x.
<alex_williamson@hp.com> (02/10/31 1.757.10.4)
ia64: Fix potential MCA and silent data corruption in HP zx1
IOMMU driver.
- Fixes a potential silent data corruption because the pdir
cache on the chipset set was getting improperly flushed.
It's very hard to hit given the allocation mechanism for the
pdir, but it is possible.
- Demangles scatter-gather pointers. The driver was taking far
too much liberty in changing these. A known MCA path caused
by this is SCSI retries, which passed back in a pre-mangled
scatter-gather array.
- Adds an option for keeping the entire iommu pdir valid. This
is really just some debugging code that I added along the way.
In the event that you've installed a device that aggressively
tries to prefetch, you may get an MCA if it prefetches beyond
it's pdir entry. New boxes shouldn't see much of this because
PCI will disconnect. Older systems w/ < rev 3.0 LBAs might
see issues. Turning this on, makes all unused pdir entries
point to a spill page that contains poisoned data. (off by
default)
- Removes platform_pci_dma_address(). With the extra scatterlist
entries, it seems reasonable for DMA engines to store the
address in dma_address. pci_dma_length is now just a macro for
sg->dma_length, this feels cleaner and reduces complexity for
DMA engines that try to coalesce. I believe it's even a
benefit for swiotlb. The sn pci_dma interface likely needs
some touchups by those that know the interface in this area.
(thanks to Grant Grundler for helping out here)
One issue I've seen, that's simply because the scatterlist is
bigger now, 64k pages and IDE don't get along. ide-dma tries
to kmalloc a _very_ large scatterlist. The algorithm factors in
PAGE_SIZE, but it only seems to produce a reasonable value if you
have 4k pages. It goes ballistic at 64k. Replacing the kmalloc/
kfree w/ a vmalloc/vfree solves the problem, but seems like it's
only a bandaid.
<willy@fc.hp.com> (02/10/31 1.757.10.3)
ia64: ACPI tidy-up.
<bjorn_helgaas@hp.com> (02/10/29 1.757.10.2)
ia64: Detect HP ZX1 AGP bridge via ACPI instead of the old, unmaintainable
"fake PCI device" scheme.
<bjorn_helgaas@hp.com> (02/10/18 1.742.2.3)
ia64: Skip blind PCI probe when root bridges are reported by ACPI.
<bjorn_helgaas@hp.com> (02/10/18 1.742.2.2)
ia64: Scan PCI buses 0-255 (not 0-254).
<bjorn_helgaas@hp.com> (02/10/09 1.717.10.2)
ia64: more scatterlist page/offset cleanup.
<bjorn_helgaas@hp.com> (02/10/04 1.706.1.6)
ia64: Optimize load/save FPU (Fenghua Yu, Intel).
<agruen@suse.de> (02/10/04 1.706.1.5)
ia64: Extended Attribute VFS syscalls.
<bjorn_helgaas@hp.com> (02/10/04 1.706.1.4)
ia64: Reserve hugetlb syscall numbers.
<bjorn_helgaas@hp.com> (02/10/03 1.706.1.3)
ia64: Remove obsolete McKinley A0 workaround.
<davidm@tiger.hpl.hp.com> (02/10/01 1.706.1.2)
ia64: Fix EFI runtime callbacks so they cannot corrupt fp regs.
<bjorn_helgaas@hp.com> (02/10/01 1.676.7.27)
ia64: support scatterlist page/offset in sba_iommu.c.
<bjorn_helgaas@hp.com> (02/09/27 1.676.7.25)
ia64: Add PCI_DMA_BUS_IS_PHYS definition.
<bjorn_helgaas@hp.com> (02/09/27 1.676.7.24)
Remove include/asm-ia64/offsets.h.
<davidm@tiger.hpl.hp.com> (02/09/27 1.676.7.23)
ia64: Create dummy file include/asm-ia64/mc146818rtc.h since ide-geometry.c continues to
insist on it.
<bjorn_helgaas@hp.com> (02/09/27 1.676.7.22)
ia64: Sync with pcibios_enable_device interface change
<davidm@tiger.hpl.hp.com> (02/09/27 1.676.7.21)
ia64: Fix edge-triggered IRQ handling. See Linus's 2.5 cset 1.611 for details.
<bjorn_helgaas@hp.com> (02/09/27 1.676.7.20)
ia64: Remove McKinley A-step config stuff.
<willy@fc.hp.com> (02/09/27 1.676.7.19)
ia64: Discard *.text.exit and *.data.exit sections.
<willy@fc.hp.com> (02/09/27 1.676.7.18)
ia64: Remove support for HP prototypes.
<davidm@tiger.hpl.hp.com> (02/09/27 1.676.7.17)
ia64: Fix narrow window during which signal could be delivered with only the memory
stack switched over to the alternate signal stack.
<davidm@tiger.hpl.hp.com> (02/09/27 1.676.7.16)
ia64: Fix return path of signal delivery for sigaltstack() case.
<eranian@hpl.hp.com> (02/09/27 1.676.7.15)
ia64: Fix perfmon error path leaks.
<eranian@hpl.hp.com> (02/09/27 1.676.7.14)
ia64: Fix perfmon error path missing unlock.
<davidm@tiger.hpl.hp.com> (02/09/27 1.676.7.13)
ia64: Fix x86 struct ipc_kludge (reported by R Sreelatha, fix proposed by
Dave Miller).
<jsm@udlkern.fc.hp.com> (02/09/27 1.676.7.12)
ia64: Preserve f11-f15 around calls into firmware.
<bjorn_helgaas@hp.com> (02/09/27 1.676.7.11)
ia64: Print EFI call status in hex, not decimal.
<bjorn_helgaas@hp.com> (02/09/27 1.676.7.10)
ia64: Rename ia64_alloc_irq to ia64_alloc_vector.
<bjorn_helgaas@hp.com> (02/09/27 1.676.7.9)
ia64: Move simeth, simserial, simscsi to arch/ia64/hp/sim.
<bjorn_helgaas@hp.com> (02/09/27 1.676.7.8)
ia64: If more than NR_CPUS found, ignore the extras.
<bjorn_helgaas@hp.com> (02/09/27 1.676.7.7)
ia64: Reserve syscall numbers 1238-1242 for AIO.
<davidm@tiger.hpl.hp.com> (02/09/27 1.676.7.6)
ia64: Fix I/O macros in asm-ia64/io.h. Based on patch by Andreas Schwab.
<t-kouchi@mvf.biglobe.ne.jp> (02/09/27 1.676.7.5)
ia64: ACPI CRS cleanup.
<schwab@suse.de> (02/09/27 1.676.7.4)
ia64: Remove many warnings.
<t-kouchi@mvf.biglobe.ne.jp> (02/09/27 1.676.7.3)
ia64: Fix iosapic debug code.
<schwab@suse.de> (02/09/27 1.676.7.2)
ia64: Add missing symbol exports for modules.
Thanks!
Bjorn
^ permalink raw reply
* Re: heatload 0.4 now with throttling support
From: Faye Pearson @ 2002-12-18 18:03 UTC (permalink / raw)
To: Malte Thoma; +Cc: ACPI-Devel
In-Reply-To: <3E00AEC8.9050906-iYtK5bfT9M8b1SvskN2V4Q@public.gmane.org>
Malte Thoma [thoma-iYtK5bfT9M8b1SvskN2V4Q@public.gmane.org] wrote:
> In which directory, in /proc/acpi or in ../thermal_zone ?
Well, everything under /proc/acpi is well-known (so far at least)
ac_adapter/
thermal_zone/
battery/
processor/
etc.
In each of those directories there may be one or more other directories
- one for each node eg.
ACAD, AC0 for AC
BAT0, BAT1, BAT2, BATR for batteries
TZ0, THRM for thermal zones.
CPU0, PROC, for processor
The only thing you can do is opendir("/proc/acpi/thermalzone"), then
readdir for each item - ignore . and .. of course.
> Wonderfull task: something to develope for machines I cannot test it for :-(
> coming along that my skills are not guru-like :-(
If you don't hardcode the directories under ac_adapter,thermal_zone etc.
then you should be ok.
> processor ->throttling
processor/*/throttling
processor/*/performance
My processor (for example) doesn't support throttling, just performance.
> thermal* -> ????
thermal_zone/*/temperature I guess :)
> battery -> state or status
Is it status or info which holds the most useful information?
> ac_adapter -> state or status
Present: yes or no is about all that's useful there I think.
Faye
--
Faye Pearson,
Covert Development
ClaraNET Ltd. Tel 020 7903 3000
I have the simplest tastes. I am always satisfied with the best.
-- Oscar Wilde
-------------------------------------------------------
This SF.NET email is sponsored by: Order your Holiday Geek Presents Now!
Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap,
MP3 Players, XBox Games, Flying Saucers, WebCams, Smart Putty.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* 3ware driver in 2.4.x and 2.5.x not compatible with 6x00 series cards
From: Nathan Neulinger @ 2002-12-18 18:10 UTC (permalink / raw)
To: linux-kernel; +Cc: uetrecht
According to 3Ware, the driver in the 2.4.x and (I assume) 2.5.x is no
longer compatible with the 6xxx series cards.
I was instructed in the below conversation (3ware contact name has been
removed) that anyone using 6xxx cards would need to downgrade to the
.016 version of the driver. This means that a single kernel build can
no longer function on multiple machines, you have to have a special build
for machines using the 6xxx card, and a different build for 7/8xxxx.
At the very least, a warning should be placed in the driver source/Configure
help noting this incompatibility.
As this is something with a significant safety impact (in our case, I believe it
may have been responsible for some filesystem corruption in addition to all of
the system hangs), the driver in the distribute kernel should probably refuse to
attach to a 6xxx card if it is known to be incompatible.
I don't know what we'll do with this situation when we move to 2.6, cause
right now, it looks like we are completely screwed. The old driver
obviously will not compile on 2.6 since the API's have changed.
We have around 30 machines with 7xxx cards, and another 15 or so with 6xxx cards.
I'd hate to think of how many other people have purchased 6xxx cards and will
not be able to upgrade to newer distributions or to 2.6 without buying new hardware.
-- Nathan
------------------------------------------------------------
Nathan Neulinger EMail: nneul@umr.edu
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216
We provide the source for both 2.4.x and 2.2.x with v16 so users can
recompile
against any kernels.
-----Original Message-----
From: Neulinger, Nathan [mailto:nneul@umr.edu]
Sent: Wednesday, December 18, 2002 9:45 AM
Subject: RE: 3ware logs
This isn't something you intend to fix? What happens when someone with a
6xxx card wants to put in a new kernel and the old version of the driver
doesn't compile with the new kernel?
I could understand if the driver weren't included in the standard kernel
source, but it is, and from what you're saying it is incompatible with 6xxx.
That will put anyone who wants to upgrade their O/S in a very bad spot,
especially when the kernel is already built with support with the built-in
driver.
-- Nathan
------------------------------------------------------------
Nathan Neulinger EMail: nneul@umr.edu
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216
> -----Original Message-----
> Sent: Wednesday, December 18, 2002 11:44 AM
> To: Neulinger, Nathan
> Subject: RE: 3ware logs
>
>
> you need to use driver v16 for firmware release 6.9 because
> newer drivers
> for the
> 7xxx and 8xxx series in part of firmware changes etc....in
> some cases, it
> may
> work but most won't
>
>
> -----Original Message-----
> From: Neulinger, Nathan [mailto:nneul@umr.edu]
> Sent: Wednesday, December 18, 2002 9:39 AM
> Subject: RE: 3ware logs
>
>
> This appears to get rid of the symptom on this machine. Do
> you have some
> idea of when the bug was introduced, or what is wrong with the current
> driver? I'd hate to have to build a special kernel with a
> downgraded driver
> for any of my machines running w/ 6xxx boards.
>
> -- Nathan
>
> ------------------------------------------------------------
> Nathan Neulinger EMail: nneul@umr.edu
> University of Missouri - Rolla Phone: (573) 341-4841
> Computing Services Fax: (573) 341-4216
>
>
> > -----Original Message-----
> > From: Neulinger, Nathan
> > Sent: Wednesday, December 18, 2002 11:22 AM
> > Subject: RE: 3ware logs
> >
> >
> > Is that code still compile compatible with current kernels? I
> > cannot downgrade the kernel to anything prior to 2.4.20-pre7
> > due to other dependencies, but if it's compile compatible I
> > can replace the 3w-xxxx.c file in the kernel and recompile.
> >
> > -- Nathan
> >
> > ------------------------------------------------------------
> > Nathan Neulinger EMail: nneul@umr.edu
> > University of Missouri - Rolla Phone: (573) 341-4841
> > Computing Services Fax: (573) 341-4216
> >
> >
> > > -----Original Message-----
> > > Sent: Wednesday, December 18, 2002 11:18 AM
> > > To: Neulinger, Nathan
> > > Subject: RE: 3ware logs
> > >
> > >
> > > can you please downgrade the driver to v16 which was the last
> > > release for
> > > the 6xxx
> > > series cards ? Thanks
> > > http://www.3ware.com/support/download.asp?code=3&id=6.9&softty
> > > pe=Driver
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Neulinger, Nathan [mailto:nneul@umr.edu]
> > > Sent: Wednesday, December 18, 2002 8:50 AM
> > > Subject: RE: 3ware logs
> > >
> > >
> > > We're just going to try replacing the card, as I can't leave
> > > this server
> > > hanging every few minutes. Got anything else you want me
> to look at?
> > >
> > > -- Nathan
> > >
> > > ------------------------------------------------------------
> > > Nathan Neulinger EMail: nneul@umr.edu
> > > University of Missouri - Rolla Phone: (573) 341-4841
> > > Computing Services Fax: (573) 341-4216
> > >
> > >
> > > > -----Original Message-----
> > > > Sent: Tuesday, December 17, 2002 5:55 PM
> > > > To: Neulinger, Nathan
> > > > Subject: RE: 3ware logs
> > > >
> > > >
> > > > does it go away if you update it driver v31 which the
> > > latest driver ?
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Nathan Neulinger [mailto:nneul@umr.edu]
> > > > Sent: Tuesday, December 17, 2002 3:42 PM
> > > > Subject: RE: 3ware logs
> > > >
> > > >
> > > > I had recently updated this card to a freshly download
> most recent
> > > > firmware. 6.9 I think. Symptom did not change.
> > > >
> > > > -- Nathan
> > > >
> > > > > which version of the driver ? output of :
> > > > > cat /proc/scsi/3w-xxxx/0
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Nathan Neulinger [mailto:nneul@umr.edu]
> > > > > Sent: Tuesday, December 17, 2002 3:33 PM
> > > > > Subject: Re: 3ware logs
> > > > >
> > > > >
> > > > > > Can you please send the 3dm logs (details page, error
> > > > log) and kernel
> > > > > > logs if they
> > > > > > are available ? Thanks
> > > > >
> > > > > There are no relevant events in 3dm. (Nothing related,
> > just a few
> > > > > scattered unrelated power resets / rebuilds.)
> > > > >
> > > > >
> > > > > Kernel logs look basically all the same:
> > > > >
> > > > > Dec 17 03:28:06 sysinst kernel: 3w-xxxx: Unknown ioctl 0x46.
> > > > > Dec 17 03:30:56 sysinst kernel: 3w-xxxx: Unknown ioctl 0x46.
> > > > > Dec 17 03:31:34 sysinst kernel: 3w-xxxx: scsi0: Unit
> #0: Command
> > > > > (0xdfeb4400) timed out, resetting card.
> > > > > Dec 17 03:31:34 sysinst kernel: 3w-xxxx: Unknown ioctl 0x46.
> > > > > Dec 17 03:32:02 sysinst kernel: 3w-xxxx: Unknown ioctl 0x46.
> > > > > Dec 17 03:32:30 sysinst kernel: 3w-xxxx: Unknown ioctl 0x46.
> > > > > Dec 17 03:33:07 sysinst kernel: 3w-xxxx: scsi0: Unit
> #0: Command
> > > > > (0xdfeb4400) timed out, resetting card.
> > > > > Dec 17 03:33:07 sysinst kernel: 3w-xxxx: Unknown ioctl 0x46.
> > > > > Dec 17 03:33:34 sysinst kernel: 3w-xxxx: Unknown ioctl 0x46.
> > > > > Dec 17 03:35:17 sysinst kernel: 3w-xxxx: scsi0: Unit
> #0: Command
> > > > > (0xdfeb4400) timed out, resetting card.
> > > > > Dec 17 03:36:19 sysinst kernel: 3w-xxxx: Unknown ioctl 0x46.
> > > > > Dec 17 03:39:42 sysinst kernel: 3w-xxxx: scsi0: Unit
> #0: Command
> > > > > (0xdfeb4400) timed out, resetting card.
> > > > > Dec 17 03:39:43 sysinst kernel: 3w-xxxx: Unknown ioctl 0x46.
> > > > > Dec 17 03:40:19 sysinst kernel: 3w-xxxx: Unknown ioctl 0x46.
> > > > > Dec 17 03:40:20 sysinst kernel: 3w-xxxx: scsi0: Unit
> #0: Command
> > > > > (0xdfeb9000) timed out, resetting card.
> > > > > Dec 17 03:41:01 sysinst kernel: 3w-xxxx: scsi0: Unit
> #0: Command
> > > > > (0xdfeb4400) timed out, resetting card.
> > > > > Dec 17 03:42:18 sysinst kernel: 3w-xxxx: Unknown ioctl 0x46.
> > > > > Dec 17 03:42:45 sysinst kernel: 3w-xxxx: Unknown ioctl 0x46.
> > > > > Dec 17 03:43:33 sysinst kernel: 3w-xxxx: scsi0: Unit
> #0: Command
> > > > > (0xdfeb4800) timed out, resetting card.
> > > > > Dec 17 03:44:28 sysinst kernel: 3w-xxxx: Unknown ioctl 0x46.
> > > > > Dec 17 03:46:10 sysinst kernel: 3w-xxxx: scsi0: Unit
> #0: Command
> > > > > (0xdfeb4600) timed out, resetting card.
> > > > >
> > > > >
> > > > >
> > > > > I've got those going back quite a while, but the content is
> > > > essentially
> > > > > the same, only thing that changes is the command tag.
> > > > >
> > > > >
> > > > > Generally, it starts to occur whenever I do much heavy disk
> > > > activity.
> > > > >
> > > > > On the other machines, with the 7400's, I don't see this
> > > > behavior, I get
> > > > > a random command timed out, but I've only seen a few of
> > > > those (under 10
> > > > > total, and never repeatedly like this one).
> > > > >
> > > > >
> > > > > I have not tried intentionally breaking the mirror and
> > > seeing if the
> > > > > symptom goes away.
> > > > >
> > > > >
> > > > > Controller SCSI ID: 0
> > > > > Monitor version:
> > > > > ME6X 1.01.00.028
> > > > > Firmware version:
> > > > > FE6X 1.02.28.053
> > > > > BIOS version:
> > > > > BE6X 1.07.02.005
> > > > > PCB version:
> > > > > Rev2
> > > > > Achip version:
> > > > > V4.40
> > > > > Pchip version:
> > > > > V5.70
> > > > > Model:
> > > > > 6200
> > > > > Serial number:
> > > > > Unknown
> > > > > Unit count:
> > > > > 1
> > > > > Unit 0
> > > > > Status:
> > > > > OK
> > > > > Capacity:
> > > > > 27.22 GB (53174992 blocks)
> > > > > Write Cache:
> > > > > In Use
> > > > > Configuration:
> > > > > Mirror (RAID 1)
> > > > > Subunit count:
> > > > > 2
> > > > >
> > > > >
> > > > > Subunit 0
> > > > > Logical drive
> > > > > status:
> > > > > OK
> > > > > Configuration:
> > > > > RAID Disk
> > > > > Physical drive
> > > > > number:
> > > > > 0
> > > > > Logical drive
> > > > > number:
> > > > > 0
> > > > > Subunit 1
> > > > > Logical drive
> > > > > status:
> > > > > OK
> > > > > Configuration:
> > > > > RAID Disk
> > > > > Physical drive
> > > > > number:
> > > > > 1
> > > > > Logical drive
> > > > > number:
> > > > > 1
> > > > > Drive count: 2
> > > > > Port 0
> > > > > Status:
> > > > > OK
> > > > > Capacity:
> > > > > 27.22 GB (53177040
> > > > > blocks)
> > > > > Model:
> > > > > Maxtor 92720U8
> > > > > Serial number:
> > > > > C804MYKC
> > > > > Unit number:
> > > > > 0
> > > > > Drive Firmware:
> > > > > Ðj+\x03\x02b
> > > > > Port 1
> > > > > Status:
> > > > > OK
> > > > > Capacity:
> > > > > 27.22 GB (53177040
> > > > > blocks)
> > > > > Model:
> > > > > Maxtor 92720U8
> > > > > Serial number:
> > > > > C804HKTC
> > > > > Unit number:
> > > > > 0
> > > > > Drive Firmware:
> > > > > Ðj+\x03\x02b
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > --
> > > >
> > > > ------------------------------------------------------------
> > > > Nathan Neulinger EMail: nneul@umr.edu
> > > > University of Missouri - Rolla Phone: (573) 341-4841
> > > > Computing Services Fax: (573) 341-4216
> > > >
> > >
> >
>
^ permalink raw reply
* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Mike Dresser @ 2002-12-18 18:09 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <3E00B871.6060408@pobox.com>
On Wed, 18 Dec 2002, Jeff Garzik wrote:
> Linux... with the exception I guess that there are multiple peer Linii
Perhaps this is the solution. Would someone please obtain a DNA sample
from Linus?
Mike
^ permalink raw reply
* Re: converting cap_set_pg() to for_each_task_pid()
From: Chris Wright @ 2002-12-18 18:04 UTC (permalink / raw)
To: William Lee Irwin III, chris, greg, linux-kernel
In-Reply-To: <20021218055742.GE12812@holomorphy.com>
* William Lee Irwin III (wli@holomorphy.com) wrote:
> I have a pending patch that converts cap_set_pg() to the
> for_each_task_pid() API. Could you review this, and if it
> pass, include it in your tree?
I have no problem with this change.
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
^ permalink raw reply
* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Jeff Garzik @ 2002-12-18 18:03 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dave Jones, Horst von Brand, linux-kernel, Alan Cox,
Andrew Morton
In-Reply-To: <Pine.LNX.4.44.0212180936550.2891-100000@home.transmeta.com>
Linus Torvalds wrote:
> On Wed, 18 Dec 2002, Dave Jones wrote:
>>The approval process does seem to be quite a lot of work though.
>>I think it was rth last year at OLS who told me that at that time
>>he'd been doing more approving of other peoples stuff than coding himself.
>
>
> I heartily disagree with the approval process for development, just
> because it gets so much in the way and just annoys people. But for
> stabilization, that's exactly what you want. So I think gcc is using the
> approval process much too much, but apparently it works for them.
gcc's approval process looks a lot like the Linux approval process.
Dave's description of rth's work sounds a lot like the Linus Role in
Linux... with the exception I guess that there are multiple peer Linii
in gcc, and they read every patch <runs for cover> More seriously, gcc
appears to be "post the patch to gcc-patches, hope someone applies it"
which is a lot more like Linux than some think :)
Jeff
^ permalink raw reply
* Re: HT Benchmarks (was: /proc/cpuinfo and hyperthreading)
From: Andrew Burgess @ 2002-12-18 17:56 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <1_0212161441436926@cichlid.com>
>Number of threads Elapsed time User Time System Time
>1 53:216 53:220 00:000
>2 29:272 58:180 00:320
>3 27:162 1:21:450 00:540
>4 25:094 1:41:080 01:250
>Elapsed is measured by the parent thread, that is not doing anything
>but wait on a pthread_join. User and system times are the sum of
>times for all the children threads, that do real work.
>The jump from 1->2 threads is fine, the one from 2->4 is ridiculous...
>I have my cpus doubled but each one has half the pipelining for floating
>point...see the user cpu time increased due to 'worst' processors and
>cache pollution on each package.
>So, IMHO and for my apps, HyperThreading is just a bad joke.
Why do you care about user time? The elapsed time went down by
4 minutes (2->4 threads), if that's a joke I don't get it :-)
New Intel Ad: "What are you going to do with your 4 minutes today?"
^ permalink raw reply
* Re: [PATCH] add dispatch_i8259_irq() to i8259.c
From: Jun Sun @ 2002-12-18 17:48 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Ralf Baechle, linux-mips, jsun
In-Reply-To: <Pine.GSO.3.96.1021217224740.7289I-100000@delta.ds2.pg.gda.pl>
On Wed, Dec 18, 2002 at 05:14:19PM +0100, Maciej W. Rozycki wrote:
> On Tue, 17 Dec 2002, Jun Sun wrote:
>
> > > > No MIPS boards are using do_slow_gettimeoffset(). We really should get
> > > > rid of it.
> > >
> > > I know none does at the moment. But are you sure there is no system that
> > > would need it and might be supported one day?
> >
> > I serisouly don't think so. Moving forward every CPU will have a CPU counter,
> > which can be used for timeoffset purpose. Even if it does not have one,
> > it will surely have some onboard high resolution timer, which can be used
> > to intra-jiffy offset purpose.
>
> Well, I do hope so, too, but you'll never know until you find out. ;-)
>
> > > Here is an example (untested) code that I would recommend. It sends
> > > explicit ACKs to the i8259As, which has the following advantages:
> > >
> > <snip>
> >
> > Cool. This code works for me.
>
> Excellent. I worked on the code a bit more and removed the spurious IRQ
> stuff. It's not really necessary -- mask_and_ack_8259A() will deal with
> it anyway (a bit less precisely, but we don't care -- they are very rare
> and drivers absolutely have to be able to deal with spurious interrupts)
> and we want the low-level IRQ handling to be fast as it's performance
> critical. At this point the function became so compact it would be
> unreasonable not to make it inline -- the generated code is 24
> instructions on my system. The positive side effect is the code won't be
> compiled for systems that don't use it.
>
> Following is a patch that I consider a candidate for submission. I
> changed the interface a bit to permit greater flexibility. I renamed the
> function to reflect the new semantic. Unless special handling is needed
> you may simply call:
>
> do_IRQ(poll_8259A_irq(), regs);
>
I actually don't like the new semantic. The main drawback is that we can't
dispatch a 8259A interrupt from assemably code, which is often needed.
What is wrong with original way of dispatching? The general interrupt
dispatching flow is that you chase the routing path until you find the final
source and do a do_IRQ(). That seems fine with i8259A case here.
While there is certain urge to create asm/i8259a.h file, if in the end all there
is two function declarations (i8259_init() and dispatch_i8259_irq()), it is not
really worth it.
Jun
^ permalink raw reply
* Re: mac address change on an eth alias
From: Petre Bandac @ 2002-12-18 17:46 UTC (permalink / raw)
To: Ray Olszewski, linux-newbie
In-Reply-To: <5.1.0.14.1.20021217144923.020a7bd0@celine>
just testing for my general knowledge
I heard that I can change the mac, I did as richard said and it went ok, and
furthermore I wanted to change the mac of the alias, which I didn't succeed
(richard's receipt gave the same mac - the mac I specifically assigned to the
alias - to both IFC and it's alias)
so, I should take the final answer as no ?
thanks,
petre
On Wednesday 18 December 2002 00:53 Anno Domini, Ray Olszewski wrote using one
of his keyboards:
> At 10:06 PM 12/17/02 +0000, pa3gcu wrote:
> >On Tuesday 17 December 2002 21:55, Petre Bandac wrote:
> >[...]
> >
> > > so I didn't get what I wanted - the mac of the alias being different
> > > than the interface's; should I presume "no can do" ?
> >
> >I myself have never used aliasing, i do however need to spoof my MAC
> >sometimes on my laptop to be able to use it on other locations for my
> > work. However thats beside the point, as far as i can see if you set a
> > different IP# then the need for another MAC is (AFAIK) not nessasary.
> >If ARP's are a problem then setting static arps may be an answer, once
> > more i have no experiance with alising, possably Ray may have some advise
> > for you.
>
> Afraid not; I've never actually used aliasing (except in trivial test
> setups).
>
> Perhaps the best next step would be for you to explain why you need the
> interfaces to respond as though they were on different physical devices
> (that is, NICs with distinct MAC addresses). With that information, then
> maybe someone here could suggest a workaround. But as far as I know, NICs
> only support a single MAC address at any moment, not multiple ones.
--
19:43:21 up 7:15, 1 user, load average: 0.42, 0.16, 0.09
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: [PATCH]: fix compiler warnings in the math-emulator
From: Juan Quintela @ 2002-12-18 17:51 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: linux mips mailing list, Ralf Baechle
In-Reply-To: <Pine.GSO.3.96.1021218173810.5977D-100000@delta.ds2.pg.gda.pl>
>>>>> "maciej" == Maciej W Rozycki <macro@ds2.pg.gda.pl> writes:
maciej> On 18 Dec 2002, Juan Quintela wrote:
>> this patch does:
>>
>> * redefine SETCX to only set cx
>> * define a new macre SETANDTESTCX for the few cases when we also want to
>> test the value set.
maciej> Is it needed? The part that returns .mx should be optimized away by the
maciej> compiler automagically if unused.
Idea was to make things compile without warnings, that way when you
change anything, you search for warnings :(
With the changes that I sent, I have put the warnings levels down to
(for IP22) to:
- 7 C warnings
- 2 Asm warnings
And some of the remaining warnings are printk(), where we mix ints &
longs all around (no problem if the code is not the same than in 64
bits, otherwise, problem :(
Later, Juan.
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
* [PATCH/RFC] New module refcounting for net_proto_family
From: Max Krasnyansky @ 2002-12-18 15:25 UTC (permalink / raw)
To: linux-kernel
Hi Folks,
It seems that new module code is going to stay with us at least for a
while :).
So it's probably time to start fixing old interfaces to use new
refcounting scheme.
Here is a patch for sock_create() and stuff that uses net_proto_family
interface. Tested with modified af_bluetooth.c and seems to work fine.
Other families are unaffected for now because their owner field == NULL.
If people are ok with this aproach I will also fix af_unix and other
families and push all fixes into my BK tree.
(URL in case if my mailer messed up spaces
http://bluez.sourceforge.net/patches/npf_refcnt_patch-2.5.52.gz)
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or
higher.
# This patch includes the following deltas:
# ChangeSet 1.888 -> 1.889
# net/socket.c 1.39 -> 1.40
# include/linux/net.h 1.7 -> 1.8
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/12/17 maxk@qualcomm.com 1.889
# Convert generic socket code to new module refcounting.
# --------------------------------------------
#
diff -Nru a/include/linux/net.h b/include/linux/net.h
--- a/include/linux/net.h Tue Dec 17 20:02:04 2002
+++ b/include/linux/net.h Tue Dec 17 20:02:04 2002
@@ -76,6 +76,8 @@
short type;
unsigned char passcred;
+
+ struct module *owner;
};
struct scm_cookie;
@@ -124,6 +126,8 @@
short authentication;
short encryption;
short encrypt_net;
+
+ struct module *owner;
};
struct net_proto
diff -Nru a/net/socket.c b/net/socket.c
--- a/net/socket.c Tue Dec 17 20:02:04 2002
+++ b/net/socket.c Tue Dec 17 20:02:04 2002
@@ -470,6 +470,8 @@
sock = SOCKET_I(inode);
+ sock->owner = NULL;
+
inode->i_mode = S_IFSOCK|S_IRWXUGO;
inode->i_sock = 1;
inode->i_uid = current->fsuid;
@@ -517,6 +519,8 @@
return;
}
sock->file=NULL;
+
+ module_put(sock->owner);
}
static int __sock_sendmsg(struct kiocb *iocb, struct socket *sock,
struct msghdr *msg, int size)
@@ -964,8 +968,9 @@
int sock_create(int family, int type, int protocol, struct socket
**res)
{
- int i;
+ struct net_proto_family *npf;
struct socket *sock;
+ int err;
/*
* Check protocol is in range
@@ -990,14 +995,8 @@
}
#if defined(CONFIG_KMOD) && defined(CONFIG_NET)
- /* Attempt to load a protocol module if the find failed.
- *
- * 12/09/1996 Marcin: But! this makes REALLY only sense, if the user
- * requested real, full-featured networking support upon
configuration.
- * Otherwise module support will break!
- */
- if (net_families[family]==NULL)
- {
+ /* Attempt to load a protocol module if the find failed. */
+ if (net_families[family]==NULL) {
char module_name[30];
sprintf(module_name,"net-pf-%d",family);
request_module(module_name);
@@ -1005,29 +1004,31 @@
#endif
net_family_read_lock();
- if (net_families[family] == NULL) {
- i = -EAFNOSUPPORT;
+
+ npf = net_families[family];
+ if (!npf || !try_module_get(npf->owner)) {
+ err = -EAFNOSUPPORT;
goto out;
}
+
+ /*
+ * Allocate the socket and allow the family to set things up. if
+ * the protocol is 0, the family is instructed to select an
appropriate
+ * default.
+ */
-/*
- * Allocate the socket and allow the family to set things up. if
- * the protocol is 0, the family is instructed to select an appropriate
- * default.
- */
-
- if (!(sock = sock_alloc()))
- {
+ sock = sock_alloc();
+ if (!sock) {
printk(KERN_WARNING "socket: no more sockets\n");
- i = -ENFILE; /* Not exactly a match, but its the
+ err = -ENFILE; /* Not exactly a match, but its the
closest posix thing */
goto out;
}
sock->type = type;
+ sock->owner = npf->owner;
- if ((i = net_families[family]->create(sock, protocol)) < 0)
- {
+ if ((err = npf->create(sock, protocol)) < 0) {
sock_release(sock);
goto out;
}
@@ -1036,7 +1037,7 @@
out:
net_family_read_unlock();
- return i;
+ return err;
}
asmlinkage long sys_socket(int family, int type, int protocol)
@@ -1201,6 +1202,9 @@
newsock->type = sock->type;
newsock->ops = sock->ops;
+ try_module_get(sock->owner);
+ newsock->owner = sock->owner;
+
err = sock->ops->accept(sock, newsock, sock->file->f_flags);
if (err < 0)
goto out_release;
--
Max Krasnyansky <maxk@qualcomm.com>
Qualcomm
^ permalink raw reply
* Re: [BUG] module-init-tools 0.9.3, rmmod modules with '-'
From: Kai Germaschewski @ 2002-12-18 17:47 UTC (permalink / raw)
To: Rusty Russell; +Cc: vamsi, Zwane Mwaikambo, lkml
In-Reply-To: <20021218022816.913AC2C238@lists.samba.org>
On Wed, 18 Dec 2002, Rusty Russell wrote:
> In message <20021217114846.A30837@in.ibm.com> you write:
> > On Tue, Dec 17, 2002 at 11:17:05AM +1100, Rusty Russell wrote:
> > >
> > > BTW, this was done for (1) simplicity, (2) so KBUILD_MODNAME can be
> > > used to construct identifiers, and (3) so parameters when the module
> > > is built-in have a consistent name.
> > >
> > Ok, I see it now, this magic happens in scripts/Makefile.lib.
> > My module has been built outside the kernel build system, that's
> > why I saw this problem.
> >
> > I guess avoiding '-' should do it, but is there a simple way to
> > correctly build (simple, test) modules outside the kernel tree now?
>
> Has there ever been a simple way?
Well, you can do
cd my_module
echo "obj-m := my_module.o" > Makefile
vi my_module.c
make -C <path/to/kernel/src> SUBDIRS=$PWD modules
That's not too bad (and basically works for 2.4 as well)
--Kai
^ permalink raw reply
* RE: Help in cross-compiler
From: Brad Barrett @ 2002-12-18 17:33 UTC (permalink / raw)
To: Chien-Lung Wu, linux-mips
In-Reply-To: <A4E787A2467EF849B00585F14C9005590689B4@dprn03.deltartp.com>
On Wednesday 18 December 2002 10:57 am, you wrote:
> I am working on the embedded linux system on bug endian mips (mips-linux).
> As I understand, I need to get the cross-compiler work on my linux-i686
> host (redhat 7.2).
> Following the Bradly's "Building a modern MIPS cross-toolchain for linux",
> I download following packages:
>
> binutils-2.11
> gcc-2.95
> glibc-2.2.5
> glibc-linuxthreads-2.2.5
>
> And following the procedue:
...
> However, I got the error_message:
...
> /usr/toolchain1-mips/lib/gcc-lib/mips-linux/2.95/../../../../mips-linux/sys
>- include/bits/mathinline.h:426:
> unknown register name `st(1)' in `asm'
...
> Does any have any idea to fix this error?
It sounds like you used the standard binutils. You should probably use H.J.
Lu's binutils (they have some MIPS patches applied), and also his gcc (same
story). They're available at:
http://ftp.kernel.org/pub/linux/devel/binutils/
ftp://ftp.linux-mips.org/pub/linux/mips/redhat/7.3/test/
> When I build the C cross-compiler, I use the "dubious hack"
> --with-headers=/usr/include copy the "MIPS host header files". Are there
> any other ways to copy the MIPS-host headers?
I never understood why anyone would use this method. If you're building a
mips-linux cross-compiler, you should have a copy of the Linux kernel source
from linux-mips.org lying around somewhere (or are you using a pre-compiled
kernel image?). Just copy the include directory from this source to a
convenient location, symbolically link asm to asm-mips and point the gcc
configure to it.
I've included below my personal build notes from a mipsel (little-endian)
cross-toolchain I built a couple months ago. Hopefully these will be helpful.
Note that I chose /opt/toolchains/mips for the installed path, rather than
/usr/local. My build system was SuSE 7.2 (gcc version 2.95.3 20010315 (SuSE)
and binutils version 2.10.91).
Also, you don't mention applying the glibc-2.2.5-mips-build-gmon.diff patch that
Brad LaRonde recommends. If you didn't apply this patch, you might also want to
do that.
Brad
----------------Build Notes------------------------------------
I relied primarily on Steven J. Hill's build script [SJH], but with several
adjustments.
H.J. Lu says only his binutils will work:
http://ftp.kernel.org/pub/linux/devel/binutils/
I got the latest version.
H.J. Lu also says to use his gcc 3.2. This is available only in source rpm
format, at:
ftp://ftp.linux-mips.org/pub/linux/mips/redhat/7.3/test/
Glibc came from the standard location:
ftp://ftp.gnu.org/gnu/glibc/
*Except*...patched with "glibc-2.2.5-mips-build-gmon.diff" from [BDL2.4].
This source also recommends the "-finline-limit=10000" CFLAG value (claims
ld.so won't work without it, and this seems to be true).
Tool versions:
Binutils v2.13.90.0.10 (H.J. Lu)
GCC v3.2 (H.J. Lu)
Glibc v2.2.5
Glibc-linuxthreads v2.2.5
Patch:
glibc-2.2.5-mips-build-gmon.diff
(http://www.ltc.com/~brad/mips/glibc-2.2.5-mips-build-gmon.diff)
-------------------------
Build Log
-------------------------
[Implied "su" to root prior to each "make install" below.]
1. Downloaded tarballs/rpms and unpacked to:
~/mipsel-cross/binutils-2.13
~/mipsel-cross/gcc-3.2
~/mipsel-cross/glibc-2.2.5
(linuxthreads is unpacked into the glibc-2.2.5 directory)
2. Binutils:
cd ~/mipsel-cross/binutils-2.13/mips
chmod 744 README
cd ..
./mips/README (apply HJ Lu's patches)
mkdir ~/mipsel-cross/mipsel-binutils
cd ~/mipsel-cross/mipsel-binutils
../binutils-2.13/configure --prefix=/opt/toolchains/mips \
--enable-targets=mips64el-linux,mipsel-linux --target=mipsel-linux \
--enable-shared
make
make install
3. Gcc (1st time)
cp -R ~/linux-2.4/include/asm-mips /opt/toolchains/mips/mipsel-linux/include
cp -R ~/linux-2.4/include/linux /opt/toolchains/mips/mipsel-linux/include
cd /opt/toolchains/mips/mipsel-linux/include
ln -s asm-mips asm
mkdir ~/mipsel-cross/mipsel-gcc
cd ~/mipsel-cross/mipsel-gcc
AR=mipsel-linux-ar RANLIB=mipsel-linux-ranlib ../gcc-3.2/configure \
--prefix=/opt/toolchains/mips --with-newlib --enable-languages=c \
--target=mipsel-linux --disable-shared --disable-threads
make
make install
4. Glibc
cd ~/mipsel-cross/glibc-2.2.5
patch -p1 -i ../glibc-2.2.5-mips-build-gmon.diff
(patch asked for name of each file to patch...had to type them in)
mkdir ~/mipsel-cross/mipsel-glibc
cd ~/mipsel-cross/mipsel-glibc
CFLAGS="-O2 -g -finline-limit=10000" LD_LIBRARY_PATH= \
BUILD_CC=gcc CC=mipsel-linux-gcc AR=mipsel-linux-ar AS=mipsel-linux-as \
RANLIB=mipsel-linux-ranlib ../glibc-2.2.5/configure \
--prefix=/opt/toolchains/mips/mipsel-linux --host=mipsel-linux \
--build=i686-pc-linux-gnu --enable-add-ons --with-elf \
--disable-profile \
--with-headers=/opt/toolchains/mips/mipsel-linux/include \
--mandir=/opt/toolchains/mips/man --infodir=/opt/toolchains/mips/info \
--enable-kernel=2.4.0
make
make install
5. Gcc (2nd time - with full glibc support)
mkdir ~/mipsel-cross/mipsel-gccfull
cd ~/mipsel-cross/mipsel-gccfull
AR=mipsel-linux-ar RANLIB=mipsel-linux-ranlib ../gcc-3.2/configure \
--prefix=/opt/toolchains/mips --enable-languages=c,c++ \
--target=mipsel-linux --enable-shared --enable-threads \
--includedir=/opt/toolchains/mips/mipsel-linux/include \
--with-gxx-include-dir=/opt/toolchains/mips/mipsel-linux/include \
--mandir=/opt/toolchains/mips/man --infodir=/opt/toolchains/mips/info \
--disable-checking
make
make install
Sources:
--------
[BDL2.4] LaRonde, Bradley D., "Building a Modern MIPS Cross-Toolchain for
Linux", v2.4, 2002-09-25,
http://www.ltc.com/~brad/mips/mips-cross-toolchain.html
[SJH]
ftp://ftp.cotw.com/Linux/MIPS/toolchain/stable/sources/mipsel-linux-toolchain-bu
ild.sh
----------------End Build Notes--------------------------------
--
Brad Barrett
Staff Engineer, Patton Electronics
brad@patton.com
^ permalink raw reply
* RE: Help in cross-compiler
From: Brad Barrett @ 2002-12-18 17:33 UTC (permalink / raw)
To: Chien-Lung Wu, linux-mips
In-Reply-To: <A4E787A2467EF849B00585F14C9005590689B4@dprn03.deltartp.com>
On Wednesday 18 December 2002 10:57 am, you wrote:
> I am working on the embedded linux system on bug endian mips (mips-linux).
> As I understand, I need to get the cross-compiler work on my linux-i686
> host (redhat 7.2).
> Following the Bradly's "Building a modern MIPS cross-toolchain for linux",
> I download following packages:
>
> binutils-2.11
> gcc-2.95
> glibc-2.2.5
> glibc-linuxthreads-2.2.5
>
> And following the procedue:
...
> However, I got the error_message:
...
> /usr/toolchain1-mips/lib/gcc-lib/mips-linux/2.95/../../../../mips-linux/sys
>- include/bits/mathinline.h:426:
> unknown register name `st(1)' in `asm'
...
> Does any have any idea to fix this error?
It sounds like you used the standard binutils. You should probably use H.J.
Lu's binutils (they have some MIPS patches applied), and also his gcc (same
story). They're available at:
http://ftp.kernel.org/pub/linux/devel/binutils/
ftp://ftp.linux-mips.org/pub/linux/mips/redhat/7.3/test/
> When I build the C cross-compiler, I use the "dubious hack"
> --with-headers=/usr/include copy the "MIPS host header files". Are there
> any other ways to copy the MIPS-host headers?
I never understood why anyone would use this method. If you're building a
mips-linux cross-compiler, you should have a copy of the Linux kernel source
from linux-mips.org lying around somewhere (or are you using a pre-compiled
kernel image?). Just copy the include directory from this source to a
convenient location, symbolically link asm to asm-mips and point the gcc
configure to it.
I've included below my personal build notes from a mipsel (little-endian)
cross-toolchain I built a couple months ago. Hopefully these will be helpful.
Note that I chose /opt/toolchains/mips for the installed path, rather than
/usr/local. My build system was SuSE 7.2 (gcc version 2.95.3 20010315 (SuSE)
and binutils version 2.10.91).
Also, you don't mention applying the glibc-2.2.5-mips-build-gmon.diff patch that
Brad LaRonde recommends. If you didn't apply this patch, you might also want to
do that.
Brad
----------------Build Notes------------------------------------
I relied primarily on Steven J. Hill's build script [SJH], but with several
adjustments.
H.J. Lu says only his binutils will work:
http://ftp.kernel.org/pub/linux/devel/binutils/
I got the latest version.
H.J. Lu also says to use his gcc 3.2. This is available only in source rpm
format, at:
ftp://ftp.linux-mips.org/pub/linux/mips/redhat/7.3/test/
Glibc came from the standard location:
ftp://ftp.gnu.org/gnu/glibc/
*Except*...patched with "glibc-2.2.5-mips-build-gmon.diff" from [BDL2.4].
This source also recommends the "-finline-limit=10000" CFLAG value (claims
ld.so won't work without it, and this seems to be true).
Tool versions:
Binutils v2.13.90.0.10 (H.J. Lu)
GCC v3.2 (H.J. Lu)
Glibc v2.2.5
Glibc-linuxthreads v2.2.5
Patch:
glibc-2.2.5-mips-build-gmon.diff
(http://www.ltc.com/~brad/mips/glibc-2.2.5-mips-build-gmon.diff)
-------------------------
Build Log
-------------------------
[Implied "su" to root prior to each "make install" below.]
1. Downloaded tarballs/rpms and unpacked to:
~/mipsel-cross/binutils-2.13
~/mipsel-cross/gcc-3.2
~/mipsel-cross/glibc-2.2.5
(linuxthreads is unpacked into the glibc-2.2.5 directory)
2. Binutils:
cd ~/mipsel-cross/binutils-2.13/mips
chmod 744 README
cd ..
./mips/README (apply HJ Lu's patches)
mkdir ~/mipsel-cross/mipsel-binutils
cd ~/mipsel-cross/mipsel-binutils
../binutils-2.13/configure --prefix=/opt/toolchains/mips \
--enable-targets=mips64el-linux,mipsel-linux --target=mipsel-linux \
--enable-shared
make
make install
3. Gcc (1st time)
cp -R ~/linux-2.4/include/asm-mips /opt/toolchains/mips/mipsel-linux/include
cp -R ~/linux-2.4/include/linux /opt/toolchains/mips/mipsel-linux/include
cd /opt/toolchains/mips/mipsel-linux/include
ln -s asm-mips asm
mkdir ~/mipsel-cross/mipsel-gcc
cd ~/mipsel-cross/mipsel-gcc
AR=mipsel-linux-ar RANLIB=mipsel-linux-ranlib ../gcc-3.2/configure \
--prefix=/opt/toolchains/mips --with-newlib --enable-languages=c \
--target=mipsel-linux --disable-shared --disable-threads
make
make install
4. Glibc
cd ~/mipsel-cross/glibc-2.2.5
patch -p1 -i ../glibc-2.2.5-mips-build-gmon.diff
(patch asked for name of each file to patch...had to type them in)
mkdir ~/mipsel-cross/mipsel-glibc
cd ~/mipsel-cross/mipsel-glibc
CFLAGS="-O2 -g -finline-limit=10000" LD_LIBRARY_PATH= \
BUILD_CC=gcc CC=mipsel-linux-gcc AR=mipsel-linux-ar AS=mipsel-linux-as \
RANLIB=mipsel-linux-ranlib ../glibc-2.2.5/configure \
--prefix=/opt/toolchains/mips/mipsel-linux --host=mipsel-linux \
--build=i686-pc-linux-gnu --enable-add-ons --with-elf \
--disable-profile \
--with-headers=/opt/toolchains/mips/mipsel-linux/include \
--mandir=/opt/toolchains/mips/man --infodir=/opt/toolchains/mips/info \
--enable-kernel=2.4.0
make
make install
5. Gcc (2nd time - with full glibc support)
mkdir ~/mipsel-cross/mipsel-gccfull
cd ~/mipsel-cross/mipsel-gccfull
AR=mipsel-linux-ar RANLIB=mipsel-linux-ranlib ../gcc-3.2/configure \
--prefix=/opt/toolchains/mips --enable-languages=c,c++ \
--target=mipsel-linux --enable-shared --enable-threads \
--includedir=/opt/toolchains/mips/mipsel-linux/include \
--with-gxx-include-dir=/opt/toolchains/mips/mipsel-linux/include \
--mandir=/opt/toolchains/mips/man --infodir=/opt/toolchains/mips/info \
--disable-checking
make
make install
Sources:
--------
[BDL2.4] LaRonde, Bradley D., "Building a Modern MIPS Cross-Toolchain for
Linux", v2.4, 2002-09-25,
http://www.ltc.com/~brad/mips/mips-cross-toolchain.html
[SJH]
ftp://ftp.cotw.com/Linux/MIPS/toolchain/stable/sources/mipsel-linux-toolchain-bu
ild.sh
----------------End Build Notes--------------------------------
--
Brad Barrett
Staff Engineer, Patton Electronics
brad@patton.com
^ permalink raw reply
* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Linus Torvalds @ 2002-12-18 17:41 UTC (permalink / raw)
To: Dave Jones; +Cc: Horst von Brand, linux-kernel, Alan Cox, Andrew Morton
In-Reply-To: <20021218165838.GD27695@suse.de>
On Wed, 18 Dec 2002, Dave Jones wrote:
>
> > I just don't know what that "something" should be. Any ideas? I thought
> > about the code freeze require buy-in from three of four people (me, Alan,
> > Dave and Andrew come to mind) for a patch to go in, but that's probably
> > too draconian for now. Or is it (maybe start with "needs approval by two"
> > and switch it to three when going into code freeze)?
>
> You'd likely need an odd number of folks in this cabal^Winner circle
> though, or would you just do it and be damned if you got an equal
> number of 'aye's and 'nay's ? 8-)
Quite frankly, I wouldn't expect a lot of dissent.
I suspect a group approach has very little inherent disagreement, and to
me the main result of having an "approval process" is to really just slow
things down and make people think about the submitting. The actual
approval itself is secondary (it _looks_ like a primary objective, but in
real life it's just the _existence_ of rules that make more of a
difference).
> The approval process does seem to be quite a lot of work though.
> I think it was rth last year at OLS who told me that at that time
> he'd been doing more approving of other peoples stuff than coding himself.
I heartily disagree with the approval process for development, just
because it gets so much in the way and just annoys people. But for
stabilization, that's exactly what you want. So I think gcc is using the
approval process much too much, but apparently it works for them.
And I think it could work for the kernel too, especially the stable
releases and for the process of getting there. I just don't really know
how to set it up well.
Linus
^ permalink raw reply
* Re: [parisc-linux] use of the parisc logo?
From: Grant Grundler @ 2002-12-18 17:27 UTC (permalink / raw)
To: Peter Lavender; +Cc: parisc
In-Reply-To: <1040206605.3192.10.camel@eeyore.sspl.net.au>
On Wed, Dec 18, 2002 at 09:16:44PM +1100, Peter Lavender wrote:
> What's the go with use of the parisc logo on web pages? Can I use it?
I'd think you'd need written permission from HP.
Can you send me off-list a brief (50 words or less) description of how you
want to use it that I can forward to a marketing/business person?
I'm amused that we've not (yet) placed it anywhere on the
parisc-linux.org web site. :^)
grant
^ permalink raw reply
* [linux-lvm] lvm2 + 2.4.20
From: NagyZ @ 2002-12-18 17:23 UTC (permalink / raw)
To: linux-lvm
hi!
i wondering.. there will be an other dm patchet for this kernel as like
for 2.5 ?
how much time does take to upgrade my lvm1 metadata to lvm2?
i have 1T+ data..
( i dont have a couple of hours.. max. 15-30 minutes )
NagyZ
^ permalink raw reply
* Re: heatload 0.4 now with throttling support
From: Malte Thoma @ 2002-12-18 17:22 UTC (permalink / raw)
To: Faye Pearson; +Cc: Ducrot Bruno, ACPI-Devel
In-Reply-To: <20021218170828.GA9127-6JSjyQ0Qj1ReoWH0uzbU5w@public.gmane.org>
Faye Pearson wrote:
>Malte Thoma [thoma-iYtK5bfT9M8b1SvskN2V4Q@public.gmane.org] wrote:
>
>
>>cat /proc/acpi/thermal_zone/THM0
>>
>>... it seems to me that there are a LOT of different
>>proc/acpi-structures :-(
>>
>>/proc/acpi/thermal/0/status
>>/proc/acpi/thermal_zone
>>/proc/acpi/thermal_zone/THRM/temperature
>>/proc/acpi/thermal_zone/THM0
>>
>>
>
>As with most ACPI things, the name of the thermal_zone is defined by the
>DSDT table, and is arbitrary. You should read everything in the
>directory.
>
>
In which directory, in /proc/acpi or in ../thermal_zone ?
>>hope that the ACPI-group stabilize this ;-)
>>
>>
>
>They can't do anything about it.
>
>
Thank you for this importent and disillusioned information :-(
>>until now heatload workes only for one CPU (i suppose the thermal_zone
>>is coherent to the counting of CPUs?)
>>
>>
>
>No, there could be a passive zone, a critical zone etc.
>
>
Wonderfull task: something to develope for machines I cannot test it for :-(
coming along that my skills are not guru-like :-(
So what can you advise me?
parsing /proc/acpi and looking for
processor ->throttling
thermal* -> ????
battery -> state or status
ac_adapter -> state or status
excpecially in the thermal zone it looks as if ther is no regularity :-(
Do you have some more hints ?
Greetings,
Malte
>
>
-------------------------------------------------------
This SF.NET email is sponsored by: Order your Holiday Geek Presents Now!
Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap,
MP3 Players, XBox Games, Flying Saucers, WebCams, Smart Putty.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* Re: How do I see all my partitions?
From: Ray Olszewski @ 2002-12-18 17:18 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <20021218104722.GA3850@neon.pearbough.net>
There is a small error of detail in axel's reply. He writes:
>To call fdisk for your primary IDE slave call "fdisk /dev/hda" and you
>will get something like this:
/dev/hda is the IDE primary *master*, not the IDE primary *slave* (which is
/dev/hdb).
At 11:47 AM 12/18/02 +0100, axel@pearbough.net wrote:
[deleted]
--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski -- Han Solo
Palo Alto, California, USA ray@comarre.com
-------------------------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Minix and Ancient UNIX are BSD'd
From: Andru Luvisi @ 2002-12-18 17:15 UTC (permalink / raw)
To: linux-8086
Looking over the archive I don't see any mention of this, so I figured I'd
let you all know in case it can be of value. I don't know about the
kernel, but I was thinking that some of the user level utilities (and
games!) could be of value, since they already fit into a 16 bit address
space.
Minix:
http://www.cs.vu.nl/~ast/minix.html
Ancient UNIX (including several BSD releases):
http://www.tuhs.org/
http://minnie.tuhs.org/PUPS/
Andru
--
Andru Luvisi, Programmer/Analyst
Quote Of The Moment:
Quidquid latine dictum sit, altum viditur.
( Whatever is said in Latin sounds profound. )
^ permalink raw reply
* Re: Difference between dummy and loopback interfaces
From: Rob Landley @ 2002-12-16 7:02 UTC (permalink / raw)
To: John Bradford, Peter T. Breuer; +Cc: ahtraps, linux-kernel
In-Reply-To: <200212101031.gBAAVTjI000445@darkstar.example.net>
On Tuesday 10 December 2002 10:31, John Bradford wrote:
> > > I can't think of a condition where a dummy device is useful (other than
> > > for simulating a blackhole device which sucks every packet sent to it).
> >
> > The dummy device is conventionally used to provide a separate interface
> > that can be used to bind the hostname to when there is no real nic in
> > the box to bind it to (binding it to loopback being a no no).
>
> Slackware binds the hostname to 127.0.0.1 by default. As pointed out
> in comments in the /etc/hosts file, it is technically incorrect, but
> it does work, and it's fine on a non-networked machine.
>
> John.
Um, random aside:
You can attach firewall rules to a dummy0 interface that you can't attach to
and alias of lo. I don't remember exactly what failed (it was a while ago),
but when I tried to "ifconfig lo:1 10.0.0.1 netmask 255.255.255.0" and then
attach a boatload of firewall rules to it, it got confused. (It had
something against -j DNAT in the OUTPUT table, if I recall. I was also
having trouble getting packets originating from the loopback interface to
route outside of the box. But again, this was a while ago, so I don't
remember exactly what was wrong. It was a roll-your-own VPN solution that
was designed for a machine with 2 network cards acting as a gateway, but
needed to run on a box that had just one network card yet wanted to
participate in the VPN...)
Moving over to the dummy interface instead of loopback made it all work.
Loopback really isn't designed to do anything but bounce packets off of
127.0.0.1 for local delivery. It's optimized for that. The dummy interface
is more generic.
Rob
(On the other hand, "ifconfig dummy0 down" doesn't actually remove its ip from
the routing table under 2.4, last I checked. Annoying, that. You've got to
ifconfig it to something else to make it stop receiving packets, even though
it's down! I hit that a LOT in testing, sshing to my own box when I didn't
mean to, and then wondering what the heck was going wrong...)
--
penguicon.sf.net - A combination Linux Expo and Science Fiction Convention
with GOHs Terry Pratchett, Eric Raymond, Pete Abrams, Illiad & CmdrTaco.
^ permalink raw reply
* Re: heatload 0.4 now with throttling support
From: Faye Pearson @ 2002-12-18 17:08 UTC (permalink / raw)
To: Malte Thoma; +Cc: Ducrot Bruno, ACPI-Devel
In-Reply-To: <3E009EB5.7010109-iYtK5bfT9M8b1SvskN2V4Q@public.gmane.org>
Malte Thoma [thoma-iYtK5bfT9M8b1SvskN2V4Q@public.gmane.org] wrote:
> cat /proc/acpi/thermal_zone/THM0
>
> ... it seems to me that there are a LOT of different
> proc/acpi-structures :-(
>
> /proc/acpi/thermal/0/status
> /proc/acpi/thermal_zone
> /proc/acpi/thermal_zone/THRM/temperature
> /proc/acpi/thermal_zone/THM0
As with most ACPI things, the name of the thermal_zone is defined by the
DSDT table, and is arbitrary. You should read everything in the
directory.
> hope that the ACPI-group stabilize this ;-)
They can't do anything about it.
> until now heatload workes only for one CPU (i suppose the thermal_zone
> is coherent to the counting of CPUs?)
No, there could be a passive zone, a critical zone etc.
Faye
--
Faye Pearson,
Covert Development
ClaraNET Ltd. Tel 020 7903 3000
Convention is the ruler of all.
-- Pindar
-------------------------------------------------------
This SF.NET email is sponsored by: Order your Holiday Geek Presents Now!
Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap,
MP3 Players, XBox Games, Flying Saucers, WebCams, Smart Putty.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* Re: [parisc-linux] quad tulip now not functional in 2.4.20
From: Grant Grundler @ 2002-12-18 17:01 UTC (permalink / raw)
To: jsoe0708; +Cc: Ryan Bradetich, Ed Schaller, parisc-linux
In-Reply-To: <3DED9A6600002207@ocpmta3.freegates.net>
On Wed, Dec 18, 2002 at 07:30:40AM +0100, jsoe0708@tiscali.be wrote:
> In eeprom.c I also suspect:
> line 193: if (ee_data[27] == 0 || ee_data[ee_data[27]] == 0) {
...
> and it works. Unforunately I do not have enough doc to actulay fix the pb.
I don't either. I made that change after reviewing the code and just
botched it. My understanding is jgarzik is rewriting tulip driver anyway.
grant
^ 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.