* Re: [OT] use of patented algorithms in the kernel ok or not?
From: Linus Torvalds @ 2003-12-19 6:10 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: linux-kernel
In-Reply-To: <20031218231137.GA13652@gnu.org>
On Thu, 18 Dec 2003, Lennert Buytenhek wrote:
>
> What am I to do? Ignore the patent? Or should I refrain from submitting
> the patch I wrote, and look for an unencumbered algorithm instead?
Don't submit, and find an unencumbered algorithm. Unless you can get the
patent holder to grant a license (it does happen).
Linus
^ permalink raw reply
* Regarding branch delay instructions in R4000
From: karthikeyan natarajan @ 2003-12-19 6:01 UTC (permalink / raw)
To: linux-mips
Hi All,
If this is not a right forum to ask this Question,
please redirect me to the appropriate one...
Since R4000 is using the 8 stage pipeline, three
instructions are already entered into the pipeline
when the branch instruction is executed. Out of these
three instructions, the first instruction will be
executed for sure.
My question is:
What happens to the other two instruction that are
in the delay slots? are they nullified?
Could anyone please shed some light on this.
Thanks much,
-karthi
=====
The expert at anything was once a beginner
________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping"
your friends today! Download Messenger Now
http://uk.messenger.yahoo.com/download/index.html
^ permalink raw reply
* Re: Domain Transitions (or the Exim4 policy)
From: Russell Coker @ 2003-12-19 5:47 UTC (permalink / raw)
To: Shane Wegner, selinux
In-Reply-To: <20031219024548.GA24510@cm.nu>
On Fri, 19 Dec 2003 13:45, Shane Wegner <shane-keyword-selinux.9d5a25@cm.nu>
wrote:
> I am new to this list and SELinux in general but have
> managed to get it running on a Debian cid system using
> Russell's packages and policies. Those policies did come
> with a sendmail policy which I have attempted to modify for
> exim4. I believe I have the file permissions pretty much
> figured out but the domain transitions are a bit confusing.
Why did you change it to exim4_t? It seems to me that as exim and sendmail
operate in the same manner it would be better to have a single policy to use
for them both. This will make it easier to maintain the policy.
> The two things I am not sure of is when exim calls
> procmail, there is a domain transition to procmail_t which
> is rather restrictive. My own personal .procmailrc file
> for example runs tmda which is a python program which in
> turn can send out response emails. procmail_t by default
> doesn't want any part of this and when procmail calls
> sendmail which is a symbolic link back to exim4, there is
> no transition back to exim4_t so exim doesn't have the
It should transition to system_mail_t.
> permissions it needs. Further, when a user sends mail, say
> echo Hello world |mail
> exim4 gets spawned but this time in the user_t domain,
> again without the necessary permissions to write to its
> spool.
In the sendmail policy it would transition to user_mail_t domain.
> I'm thinking maybe procmail should run as user_r:user_t as
> a users procmail process should be able to do anything the
> logged in user can do. Would that be a better way of doing
> things?
Then if someone manages to take control over procmail they get complete access
to your account.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
--
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
* Plea for help
From: Ian Pilcher @ 2003-12-19 5:41 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
I posted a couple of weeks ago about a kernel panic that shows up when I
boot my Abit VP6 (dual-PIII) with ACPI turned on. It turns out that the
kernel boots just fine with ACPI on when I build it with
CONFIG_DEBUG_SLAB=y.
Alan Cox suggested that this is probably due to code that kmallocs
memory and then relies on its content without clearing it, but I never
received any response to my request for suggestions on how to identify
the offending code.
I've just spent several hours adding printk statements to the ACPI code,
and I've reached a point where the oops message is overwriting portions
of my printk messages. I have the sinking feeling that this indicates
that the process executing the ACPI code is not the one that's oops'ing.
I'm stuck. How can a relative newbie debug a problem like this, or at
least gather enough information to enable someone with more expertise to
do so?
TIA.
--
========================================================================
Ian Pilcher i.pilcher-Wuw85uim5zDR7s880joybQ@public.gmane.org
========================================================================
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
^ permalink raw reply
* Re: Catching NForce2 lockup with NMI watchdog
From: Ross Dickson @ 2003-12-19 5:38 UTC (permalink / raw)
To: Craig Bradney, Maciej W. Rozycki; +Cc: george, linux-kernel
In-Reply-To: <1071757363.18749.42.camel@athlonxp.bradney.info>
On Friday 19 December 2003 00:22, Craig Bradney wrote:
> Just as an FYI, still going strong here with the old api and ioapic
> patches. 5d 20h now.
>
> When the official 2.6.0 comes to Gentoo Linux I can try that with
> whatever patches people are finding stable for these nforce fixes.
>
> Anyone had any luck in talking to ASUS re a BIOS update?
>
> Craig
>
I have not talked to ASUS. I note from peoples postings that with the
latest award bios we may need no apic patches (C1 disconnect auto),
just an ioapic one to work round a buggy bios. I don't think you can run
nmi_watchdog=1 with the old io-apic (not of my doing) patch.
I have pheonix bios MOBOS from albatron and epox so award bios doesn't help me.
No disconnect options available in setup.
My apic ack delay patch lets the bios have its disconnect on and keep the cpu a
few degrees cooler besides whatever else it and the nforce2 chipset might want
to control it for.
I have been advised my query wrt my apic ack delay patch is progressing
with AMD but I have nothing technical to report on it.
I have made and am trialling, but have not yet posted a kernel arg controlled
version combining my v1 and v2 apic ack delay patches. This would be better
than what I have released in the past because people can fix bioses as the
fixes become available and use timer ack delay in the mean time.
Of course there is still athcool and the earlier disconnect patch to force
things if desired.
Regards
Ross.
^ permalink raw reply
* Re: [CFT][RFC] HT scheduler
From: Nick Piggin @ 2003-12-19 5:13 UTC (permalink / raw)
To: Rusty Russell
Cc: linux-kernel, Anton Blanchard, Ingo Molnar, Martin J. Bligh,
Nakajima, Jun, Mark Wong, John Hawkes
In-Reply-To: <3FE28529.1010003@cyberone.com.au>
Nick Piggin wrote:
>
> Easier said than done... anyway, how does this patch look?
> It should also cure a possible and not entirely unlikely use
> after free of the task_struct in sched_migrate_task on NUMA
> AFAIKS.
Err, no of course it doesn't because its executed by said task.
So the get/put_task_struct can go.
^ permalink raw reply
* Re: [patch] 2.6.0 MCA TLB error recovery
From: Keith Owens @ 2003-12-19 5:06 UTC (permalink / raw)
To: linux-ia64
On Thu, 18 Dec 2003 15:37:09 -0800,
"Luck, Tony" <tony.luck@intel.com> wrote:
>It looks like salinfo_log_wakeup() is called right before
>ia64_log_print() ... so I'm not sure why the salinfo_decode
>daemon kept on snoozing. Keith: am I missing something obvious?
From the top of salinfo_log_wakeup()
* ... MCA and INIT events are
* not irq safe, do not call any routines that use spinlocks, they may deadlock.
MCA and INIT records are noted but it is not safe to call up() from
those interrupts, so the daemon cannot be woken. This has not been a
problem in the past because MCA and INIT were not recoverable, the
records are picked up on the next boot. Once my patches are in David's
tree, I will update salinfo to periodically check for any MCA or INIT
records and kick the daemon. There was no point before, I had no way
of testing this case.
^ permalink raw reply
* [LARTC] Problems using The Ultimate Traffic Conditioner from the Cookbook
From: Malte Starostik @ 2003-12-19 5:06 UTC (permalink / raw)
To: lartc
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I'm absolutely new to tc and found The Ultimate Traffic Conditioner to be
exactly what I wanted as a starting point.
Now the script doesn't behave as I expected though, which applies to both the
CBQ and HTB versions, the latter of which being my preference.
The only changes made to the script are these assignments:
DOWNLINKr0
UPLINK\x110
DEV=ppp0
and s/^tc/\/sbin/tc/ so it can be run via sudo (no /sbin in $PATH then)
My ISP provides ADSL at 768kbps up/128kbps down.
Now with the above configuration downloads still come in at normal speed (~88
kbytes/s with ftp), latency increases like without any traffic control and
according to tc -s no packet is dropped at all.
So I played a bit with the DOWNLINK value and found out that down to and
including 555 no packets are dropped even if a download fully saturates the
link while 554 already drastically caps the download to ~65 kbytes/s, and
there are packets being dropped:
Sent 2788072 bytes 2611 pkts (dropped 461, overlimits 0)
Lower values than 554 drop even more packets, just as I'd expect; there seems
to be no other threshold as hard as from 554 to 555.
Now I fail to see any meaning in these values, the download speed I get when
using them and especially what happens at 555 (supposed to be kbits/s,
right?).
Any insight is greatly appreciated!
Some specs (don't hesitate to solicit any more info if needed):
$ uname -a
Linux zaphod.bound-souls 2.4.20-gentoo-r7 #2 Fri Dec 19 03:28:33 CET 2003 i686
Pentium II (Klamath) GenuineIntel GNU/Linux
$ /sbin/ip addr show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:80:c8:d7:fe:1b brd ff:ff:ff:ff:ff:ff
inet 172.16.0.1/24 brd 172.16.0.255 scope global eth0
inet6 fe80::280:c8ff:fed7:fe1b/10 scope link
inet6 3ffe:b80:24b:1::1/64 scope global
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:00:e8:45:97:a9 brd ff:ff:ff:ff:ff:ff
inet6 fe80::200:e8ff:fe45:97a9/10 scope link
4: sit0@NONE: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
5: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc htb qlen 3
link/ppp
inet 217.232.54.6 peer 217.5.98.175/32 scope global ppp0
6: ippp0: <POINTOPOINT,NOARP> mtu 1500 qdisc noop qlen 30
link/ppp
7: sit1@NONE: <POINTOPOINT,NOARP,UP> mtu 1472 qdisc noqueue
link/sit 0.0.0.0 peer 206.123.31.114
inet6 fe80::d9e8:3606/10 scope link
inet6 fe80::ac10:1/10 scope link
inet6 3ffe:b80:2:c97::2/128 scope global
The DSL modem used by ppp0 is connected directly to eth1.
There are quite some non-fancy iptables rules in effect, as set up by a very
basic shorewall configuration.
The box is pretty damn idle.
Thanks alot in advance,
Malte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/4odYVDF3RdLzx4cRAjKYAKCo1GpMrHPL7T3ddBqpLYABf+ivbQCg0S1p
2+LTZ6aOvSF/STInht1XClA=xzeC
-----END PGP SIGNATURE-----
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: Capturing output of a process.
From: Progga @ 2003-12-19 5:05 UTC (permalink / raw)
To: Glynn Clements; +Cc: linux-c-programming
In-Reply-To: <16354.21736.871304.763744@cerise.nosuchdomain.co.uk>
On Fri, Dec 19, 2003 at 01:31:20AM +0000, Glynn Clements wrote:
> Most practical solutions involve allocating a pseudo-tty *before*
> starting the process whose output is to be logged.
If I want to write something LIKE an SSL server, should I follow this same
technique to capture the output of a child process ?
Khoda Hafez
Progga
^ permalink raw reply
* 2.6.0 incorrect memory sizing (without a full BIOS)..
From: Dave Airlie @ 2003-12-19 5:04 UTC (permalink / raw)
To: linux-kernel
Hi all,
I've got an internal development board based on the Intel 815
chipset and the Intel ACSFL mini-BIOS for embedded systems, and then using
grub 0.93 to boot Linux.
under 2.4 my memory is correctly sized at 256MB, but under 2.6 I'm only
seeing 64MB,
2.6 gives:
BIOS-provided physical RAM map:
BIOS-88: 0000000000000000 - 000000000009f000 (usable)
BIOS-88: 0000000000100000 - 00000000040ffc00 (usable)
64MB LOWMEM available
2.4 gives:
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
BIOS-e820: 00000000000e0000 - 0000000000100000 type 5
BIOS-e820: 0000000000100000 - 000000000ff00000 (usable)
BIOS-e820: 000000000ff00000 - 0000000010000000 (reserved)
BIOS-e820: 00000000fec00000 - 00000000fec00400 type 6
BIOS-e820: 00000000fee00000 - 00000000fee00400 type 7
BIOS-e820: 00000000fff00000 - 0000000100000000 type 5
So is this 2.6 just being more fussy about the contents of the e820 that
my "BIOS" is supplying and falling back to the old style detection?
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
^ permalink raw reply
* [parisc-linux] Update palo to autodetect Serial Mux and append console=ttyB0
From: Ryan Bradetich @ 2003-12-19 4:58 UTC (permalink / raw)
To: bame; +Cc: parisc-linux
[-- Attachment #1: Type: text/plain, Size: 617 bytes --]
Hello Paul and parisc-linux hackers,
I got an itch to update palo to auto-detect the serial mux and append
the console=ttyB0 to the kernel commandline like it does for tty0 and
ttyS0.
The following patch impliments this update (scrach one itch).
I have successfully booted 2.6.0-pa0 on C200+ and K460 using both tftp'd
kernels and on-disk kernels.
Feedback and/or testing welcome.
thanks,
- Ryan
P.S. This patch has not been commited to the palo cvs. Feel free to
commit the patch if you approve it Paul; or let me know what needs to be
updated (version?, changelog entry?, etc) if you want me to commit it.
[-- Attachment #2: palo.diff --]
[-- Type: text/x-patch, Size: 3217 bytes --]
Index: ipl/bootloader.h
===================================================================
RCS file: /var/cvs/palo/ipl/bootloader.h,v
retrieving revision 1.11
diff -u -p -r1.11 bootloader.h
--- ipl/bootloader.h 7 Jan 2002 23:55:10 -0000 1.11
+++ ipl/bootloader.h 19 Dec 2003 03:39:41 -0000
@@ -29,6 +29,7 @@ void die(const char *);
void firmware_init(int started_wide);
void pdc_default_width(int wide);
int pdc_cons_duplex();
+int pdc_cons_mux(int *is_mux);
int pdc_iodc_cin(char *buf, int size);
void pdc_iodc_cout(const char *c, int size);
int pdc_os_bits();
Index: ipl/ipl.c
===================================================================
RCS file: /var/cvs/palo/ipl/ipl.c,v
retrieving revision 1.32
diff -u -p -r1.32 ipl.c
--- ipl/ipl.c 13 Jan 2003 19:41:24 -0000 1.32
+++ ipl/ipl.c 19 Dec 2003 03:39:41 -0000
@@ -7,9 +7,13 @@
*/
#include <stddef.h>
#include "bootloader.h"
+#include <asm/pdc.h>
#include <asm/byteorder.h>
#include "load.h"
+#undef PAGE0
+#define PAGE0 ((struct zeropage *)0x00000000)
+
int Debug = 0;
void flush_data_cache(char *start, size_t length)
@@ -320,11 +324,22 @@ iplmain(int is_interactive, char *initia
printf("\nInformation: No console specified on kernel command line."
" This is normal.\nPALO will choose the console currently"
" used by firmware ");
+
strcat(f.cmdline, " console=");
if (pdc_cons_duplex())
{
+ int is_mux;
+
printf("(serial).\n");
- strcat(f.cmdline, "ttyS0");
+
+ if(pdc_cons_mux(&is_mux) != PDC_OK)
+ printf("Informatin: The PDC calls to query the console device failed. Assuming console=ttyS0\n");
+
+ if(is_mux)
+ strcat(f.cmdline, "ttyB0");
+ else
+ strcat(f.cmdline, "ttyS0");
+
if (strstr(f.cmdline, " TERM=") == 0)
strcat(f.cmdline, " TERM=vt102");
}
Index: ipl/pdc_misc.c
===================================================================
RCS file: /var/cvs/palo/ipl/pdc_misc.c,v
retrieving revision 1.14
diff -u -p -r1.14 pdc_misc.c
--- ipl/pdc_misc.c 7 Jan 2002 23:55:10 -0000 1.14
+++ ipl/pdc_misc.c 19 Dec 2003 03:39:41 -0000
@@ -20,6 +20,8 @@
#define PDC_RETURN_DEFAULTS 1
#define PDC_SET_DEFAULTS 2
#define PDC_STABLE 10
+#define HPHW_A_DIRECT 5
+#define MUX_SVERSION 0x0d
void die(const char *s)
{
@@ -221,6 +223,37 @@ int
pdc_cons_duplex()
{
return (PAGE0->mem_cons.cl_class == CL_DUPLEX);
+}
+
+int
+pdc_cons_mux(int *is_mux)
+{
+ int r;
+ unsigned char hw_type; /* 5 bits used */
+ unsigned int sversion; /* 20 bits used */
+ unsigned pdc_result2[64] __attribute__ ((aligned (8)));
+
+ *is_mux = 0;
+
+ r = firmware_call(mem_pdc, PDC_IODC, PDC_IODC_READ,
+ pdc_result, PAGE0->mem_cons.hpa,
+ 0, pdc_result2, 32);
+
+ if (r >= 0)
+ {
+ unsigned char iodc_data[32];
+ memcpy(&iodc_data, pdc_result2, 32);
+
+ hw_type = iodc_data[3] & 0x1f;
+ sversion = ((iodc_data[4] & 0x1f) << 16) | (iodc_data[5] << 8) | iodc_data[6];
+
+ if(hw_type == HPHW_A_DIRECT && sversion == MUX_SVERSION)
+ *is_mux = 1;
+
+ return PDC_OK;
+ }
+
+ return r; /* r < 0; error */
}
int
^ permalink raw reply
* Re: [CFT][RFC] HT scheduler
From: Nick Piggin @ 2003-12-19 4:57 UTC (permalink / raw)
To: Rusty Russell
Cc: linux-kernel, Anton Blanchard, Ingo Molnar, Martin J. Bligh,
Nakajima, Jun, Mark Wong, John Hawkes
In-Reply-To: <3FDE3EF7.7000001@cyberone.com.au>
[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]
Nick Piggin wrote:
>
>
> Rusty Russell wrote:
>
>>
>> A few things need work:
>>
>> 1) There's a race between sys_sched_setaffinity() and
>> sched_migrate_task() (this is nothing to do with your patch).
>>
>
> Yep. They should both take the task's runqueue lock.
Easier said than done... anyway, how does this patch look?
It should also cure a possible and not entirely unlikely use
after free of the task_struct in sched_migrate_task on NUMA
AFAIKS.
Patch is on top of a few other changes so might not apply, just
for review. I'll release a new rollup with this included soon.
>
>
>>
>> 2) Please change those #defines into an enum for idle (patch follows,
>> untested but trivial)
>>
>
> Thanks, I'll take the patch.
done
>
>>
>> 3) conditional locking in load_balance is v. bad idea.
>>
>
> Yeah... I'm thinking about this. I don't think it should be too hard
> to break out the shared portion.
done
>
>
>>
>> 4) load_balance returns "(!failed && !balanced)", but callers stop
>> calling it when it returns true. Why not simply return "balanced",
>> or at least "balanced && !failed"?
>>
>>
>
> No, the idle balancer stops calling it when it returns true, the periodic
> balancer sets idle to 0 when it returns true.
>
> !balanced && !failed means it has moved a task.
>
> I'll either comment that, or return it in a more direct way.
>
done
[-- Attachment #2: sched-migrate-affinity-race.patch --]
[-- Type: text/plain, Size: 4423 bytes --]
Prevents a race where sys_sched_setaffinity can race with sched_migrate_task
and cause sched_migrate_task to restore an invalid cpu mask.
linux-2.6-npiggin/kernel/sched.c | 89 +++++++++++++++++++++++++++++----------
1 files changed, 68 insertions(+), 21 deletions(-)
diff -puN kernel/sched.c~sched-migrate-affinity-race kernel/sched.c
--- linux-2.6/kernel/sched.c~sched-migrate-affinity-race 2003-12-19 14:45:58.000000000 +1100
+++ linux-2.6-npiggin/kernel/sched.c 2003-12-19 15:19:30.000000000 +1100
@@ -947,6 +947,9 @@ static inline void double_rq_unlock(runq
}
#ifdef CONFIG_NUMA
+
+static inline int __set_cpus_allowed(task_t *p, cpumask_t new_mask, unsigned long *flags);
+
/*
* If dest_cpu is allowed for this process, migrate the task to it.
* This is accomplished by forcing the cpu_allowed mask to only
@@ -955,16 +958,43 @@ static inline void double_rq_unlock(runq
*/
static void sched_migrate_task(task_t *p, int dest_cpu)
{
- cpumask_t old_mask;
+ runqueue_t *rq;
+ unsigned long flags;
+ cpumask_t old_mask, new_mask = cpumask_of_cpu(dest_cpu);
+ rq = task_rq_lock(p, &flags);
old_mask = p->cpus_allowed;
- if (!cpu_isset(dest_cpu, old_mask))
+ if (!cpu_isset(dest_cpu, old_mask)) {
+ task_rq_unlock(rq, &flags);
return;
+ }
+
+ get_task_struct(p);
+
/* force the process onto the specified CPU */
- set_cpus_allowed(p, cpumask_of_cpu(dest_cpu));
+ if (__set_cpus_allowed(p, new_mask, &flags) < 0)
+ goto out;
+
+ /* __set_cpus_allowed unlocks the runqueue */
+ rq = task_rq_lock(p, &flags);
+ if (unlikely(p->cpus_allowed != new_mask)) {
+ /*
+ * We have raced with another set_cpus_allowed.
+ * old_mask is invalid and we needn't move the
+ * task back.
+ */
+ task_rq_unlock(rq, &flags);
+ goto out;
+ }
+
+ /*
+ * restore the cpus allowed mask. old_mask must be valid because
+ * p->cpus_allowed is a subset of old_mask.
+ */
+ __set_cpus_allowed(p, old_mask, &flags);
- /* restore the cpus allowed mask */
- set_cpus_allowed(p, old_mask);
+out:
+ put_task_struct(p);
}
/*
@@ -2603,31 +2633,27 @@ typedef struct {
} migration_req_t;
/*
- * Change a given task's CPU affinity. Migrate the thread to a
- * proper CPU and schedule it away if the CPU it's executing on
- * is removed from the allowed bitmask.
- *
- * NOTE: the caller must have a valid reference to the task, the
- * task must not exit() & deallocate itself prematurely. The
- * call is not atomic; no spinlocks may be held.
+ * See comment for set_cpus_allowed. calling rules are different:
+ * the task's runqueue lock must be held, and __set_cpus_allowed
+ * will return with the runqueue unlocked.
*/
-int set_cpus_allowed(task_t *p, cpumask_t new_mask)
+static inline int __set_cpus_allowed(task_t *p, cpumask_t new_mask, unsigned long *flags)
{
- unsigned long flags;
migration_req_t req;
- runqueue_t *rq;
+ runqueue_t *rq = task_rq(p);
- if (any_online_cpu(new_mask) == NR_CPUS)
+ if (any_online_cpu(new_mask) == NR_CPUS) {
+ task_rq_unlock(rq, flags);
return -EINVAL;
+ }
- rq = task_rq_lock(p, &flags);
p->cpus_allowed = new_mask;
/*
* Can the task run on the task's current CPU? If not then
* migrate the thread off to a proper CPU.
*/
if (cpu_isset(task_cpu(p), new_mask)) {
- task_rq_unlock(rq, &flags);
+ task_rq_unlock(rq, flags);
return 0;
}
/*
@@ -2636,18 +2662,39 @@ int set_cpus_allowed(task_t *p, cpumask_
*/
if (!p->array && !task_running(rq, p)) {
set_task_cpu(p, any_online_cpu(p->cpus_allowed));
- task_rq_unlock(rq, &flags);
+ task_rq_unlock(rq, flags);
return 0;
}
+
init_completion(&req.done);
req.task = p;
list_add(&req.list, &rq->migration_queue);
- task_rq_unlock(rq, &flags);
+ task_rq_unlock(rq, flags);
wake_up_process(rq->migration_thread);
-
wait_for_completion(&req.done);
+
return 0;
+
+}
+
+/*
+ * Change a given task's CPU affinity. Migrate the thread to a
+ * proper CPU and schedule it away if the CPU it's executing on
+ * is removed from the allowed bitmask.
+ *
+ * NOTE: the caller must have a valid reference to the task, the
+ * task must not exit() & deallocate itself prematurely. The
+ * call is not atomic; no spinlocks may be held.
+ */
+int set_cpus_allowed(task_t *p, cpumask_t new_mask)
+{
+ unsigned long flags;
+ runqueue_t *rq;
+
+ rq = task_rq_lock(p, &flags);
+
+ return __set_cpus_allowed(p, new_mask, &flags);
}
EXPORT_SYMBOL_GPL(set_cpus_allowed);
_
^ permalink raw reply
* Re: [uml-devel] [UML patch] fixes for !CONFIG_PROC_MM, 2.6.0
From: Jeff Chua @ 2003-12-19 4:35 UTC (permalink / raw)
To: Ingo Molnar; +Cc: UML devel list, Jeff Dike
In-Reply-To: <Pine.LNX.4.58.0312181514140.7622@earth>
On Thu, 18 Dec 2003, Ingo Molnar wrote:
> redhat.com/~mingo/UML-patches/uml-combo-2.6.0-A2
Can't compile. Got the following error ...
my .config has these ...
# CONFIG_MODE_TT is not set
# CONFIG_STATIC_LINK is not set
CONFIG_MODE_SKAS=y
Also, Reiser4 patch linux-2.6.0-test9-reiser4.diff.gz can't be used with
uml-combo-2.6.0-A2.
Thanks,
Jeff
make -f scripts/Makefile.build obj=arch/um/util
gcc -o arch/um/util/mk_task_user.o -c arch/um/util/mk_task_user.c
CC arch/um/util/mk_task_kern.o
In file included from include/asm/thread_info.h:13,
from include/linux/thread_info.h:21,
from include/linux/spinlock.h:12,
from include/linux/capability.h:45,
from include/linux/sched.h:7,
from arch/um/util/mk_task_kern.c:1:
include/asm/processor.h:66: `CONFIG_X86_L1_CACHE_SHIFT' undeclared here
(not in a function)
include/asm/processor.h:66: requested alignment is not a constant
arch/um/util/mk_task_kern.c: In function `main':
arch/um/util/mk_task_kern.c:13: structure has no member named `regs'
make[1]: *** [arch/um/util/mk_task_kern.o] Error 1
make: *** [arch/um/util] Error 2
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
* How to control RTS signal ?
From: yhxing @ 2003-12-19 4:50 UTC (permalink / raw)
To: linuxppc-embedded@lists.linuxppc.org
Hi,
Now we are using a mpc823 embedded system, and there is some trouble.
We need to use SCC3 UART to control RS485 tranceiver. TXD3 is connected
to RS485 tranceiver's D pin, RXD3 is connected to RS485 tranceiver's R
pin, and RTS3 is connected to RS485 tranceiver's RE# and DE pin. Then
when transmitting data, we hope RTS3 signal can keep low to enble D.
When receiving data, we hope RTS3 signal can keep high to enble R.
So my question is, how can I program to control RTS3 signal in ppclinux.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: kernel 2.60-test11 - NFS server oddness
From: Mike Fedyk @ 2003-12-19 4:42 UTC (permalink / raw)
To: hanasaki; +Cc: Linux - LIST
In-Reply-To: <3FCEBF85.3040602@hanaden.com>
On Wed, Dec 03, 2003 at 11:00:53PM -0600, hanasaki wrote:
> nfs v3 on TCP
> Kernel 2.4.23
>
> = File Server =
> nfs v3 on TCP
> kernell 2.6 test11
>
> = NFS = All NFS is v3 on TCP
Can you try NFS on udp?
^ permalink raw reply
* 2.6.0: reiserfs errors: reiserfs_read_locked_inode and friends
From: fire-eyes @ 2003-12-19 4:39 UTC (permalink / raw)
To: linux-kernel
Hi, thanks for taking the time to read this.
I have been experimenting between 2.4.23 and 2.6.0-test{5,6,7,8,9,10,11}
and now 2.6.0.
Starting with -test11, I noticed often that I could not perform a
startx, and as root got permission denied trying to execute or even list
some files. I also notice this in 2.6.0. Dropping back to 2.4.23, I can
perform the mentioned actions.
My motherboard is an Asus A7M266-D, and I run two AMD XP 1800+ CPU's. I
am using a Seagate ST3120023A IDE disk drive.
Here is what I'm seeing in logs:
Dec 18 22:29:40 localhost kernel: blk: queue dfd8fc00, I/O limit 4095Mb
(mask 0xffffffff)
Dec 18 22:29:40 localhost kernel: hda: dma_intr: status=0x58 {
DriveReady SeekComplete DataRequest }
Dec 18 22:29:40 localhost kernel:
Dec 18 22:29:40 localhost kernel: hda: set_drive_speed_status:
status=0x58 { DriveReady SeekComplete DataRequest }
Dec 18 22:29:40 localhost kernel: ide0: Drive 0 didn't accept speed
setting. Oh, well.
Dec 18 22:29:40 localhost kernel: blk: queue dfd8f800, I/O limit 4095Mb
(mask 0xffffffff)
Dec 18 22:29:40 localhost kernel: is_tree_node: node level 0 does not
match to the expected one 2
Dec 18 22:29:40 localhost kernel: vs-5150: search_by_key: invalid format
found in block 8397. Fsck?
Dec 18 22:29:40 localhost kernel: vs-13070: reiserfs_read_locked_inode:
i/o failure occurred trying to find stat data of [373169 373
170 0x0 SD]
Dec 18 22:29:48 localhost kernel: eth0: no IPv6 routers present
Dec 18 22:29:54 localhost kernel: is_tree_node: node level 0 does not
match to the expected one 2
Dec 18 22:29:54 localhost kernel: vs-5150: search_by_key: invalid format
found in block 8397. Fsck?
Dec 18 22:29:54 localhost kernel: vs-13070: reiserfs_read_locked_inode:
i/o failure occurred trying to find stat data of [388986 388
990 0x0 SD]
Here is what i'm passing to 2.6.0 via grub:
root=/dev/hda6 ide0=autotune ide1=autotune
The kernel claims the reiserfs partitions are "3.6" format.
Any other information I can give to assist?
^ permalink raw reply
* samba problems
From: Lee Robbins @ 2003-12-19 4:33 UTC (permalink / raw)
To: linux-kernel
I'm having a weird problem since upgrading to kernel 2.6, I have 2
drives mounted through samba but if the samba machine goes down for a
reboot and then comes back I can no longer ls the dir that has the dir's
i am using for the mount points. I have to manually unmount and remount
to be able to ls or do anything in that directory. I can't browse for
files with xine either. It's like the machine going down freezes that
directory.
With 2.4.21 the machine with the samba shares would go down for reboot
(windows gaming machine) and I could ls in the directory (home/username/
which would contain /home/username/share1 etc..) and browse with xine
etc..
I'm running gentoo linux 1.4 with 2.6test11
^ permalink raw reply
* Re: Catching NForce2 lockup with NMI watchdog
From: Ross Dickson @ 2003-12-19 4:17 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: George Anzinger, linux-kernel
In-Reply-To: <Pine.LNX.4.55.0312181525070.23601@jurand.ds.pg.gda.pl>
On Friday 19 December 2003 00:32, Maciej W. Rozycki wrote:
> On Thu, 18 Dec 2003, Ross Dickson wrote:
>
> > I grabbed the manuals that google search found. By the look of it what I had
> > covered P3 and earlier. Yours are more up to date and cover P4.
>
> Newer manuals sometimes lack details that are present in older ones. If
> you want to have a thorough view of the APIC, you certainly want to have
> all four variations of processor manuals, i.e. the one for P4+, the one
> for PII+, the one for PPro and the one for Pentium. Plus manuals for the
> I/O APIC, e.g. the one for the i82093AA and perhaps for ones embedded into
> various chipsets. All of them are or used to be available online. If you
> want to go back to the i82489DX, there is a datasheet and a programming
> manual for the part, which are IMO the most exhaustive descriptions,
> though the implementation differed a bit from newer ones (the chip was so
> far the most powerful implementation of the APIC). These were
> unfortunately never available online.
>
Point taken, I generally play embedded MPU where the codebase matches the
specific hardware version and one set of docs suffice, although it is not
uncommon to rediscover an unpublished bug.
This one codebase for all hardware certainly is a lot more work!
Do you know if the Athlon apic programming docs are available or under NDA?
I do not even want to ask about the nvidia nforce2 chipset.
Regards
Ross.
> --
> + Maciej W. Rozycki, Technical University of Gdansk, Poland +
> +--------------------------------------------------------------+
> + e-mail: macro@ds2.pg.gda.pl, PGP key available +
>
>
>
^ permalink raw reply
* Re: [linux-lvm] Changing PV position
From: Heinz J . Mauelshagen @ 2003-12-19 4:15 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <200312181208.49303.benoit.peccatte@enst-bretagne.fr>
On Thu, Dec 18, 2003 at 12:08:49PM +0100, Benoit wrote:
> Hello,
>
> I'm currently using lvm on my box and one disk just died.
> Then the second disk (hdb) became the first one (hda). The problem is that now
> I can't get back the physical volume which is on it. Is it possible to tell
> lvm to force the reading of a PV even if it isn't on the same disk as
> before ?
vgscan does whyt you are asking for (before trying "vgchange -ay").
>
> Thank you for your help.
> Benoit
>
>
> Informations :
>
> peck:/# fdisk -l /dev/hda
>
> Disk /dev/hda: 122.9 GB, 122942324736 bytes
> 255 heads, 63 sectors/track, 14946 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
>
> Device Boot Start End Blocks Id System
> /dev/hda1 * 1 898 7213153+ b W95 FAT32
> /dev/hda2 899 1384 3903795 83 Linux
> /dev/hda3 1385 14946 108936765 5 Extended
> /dev/hda5 1385 1992 4883728+ fd Linux raid autodetect
> /dev/hda6 1993 14946 104052973+ 8e Linux LVM
>
> peck:/# pvs /dev/hda6
> Failed to read physical volume "/dev/hda6"
>
>
> I'm currently using linux 2.6-test9, with lvm2 tools.
> The missing volume was created with lvm1 tools.
>
>
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
--
Regards,
Heinz -- The LVM Guy --
*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf
Germany
Mauelshagen@Sistina.com +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply
* Re: USB on MIPS
From: Kunihiko IMAI @ 2003-12-19 4:14 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <20031218094321.A4146@mvista.com>
Hi,
At Thu, 18 Dec 2003 09:43:21 -0800,
Jun Sun wrote:
>
> On Thu, Dec 18, 2003 at 07:58:36PM +0530, samavarthy c wrote:
> > Hi,
(snip)
>
> Another possiblity (which is probably more likely) is the IRQ
> number is not seupt correctly.
And another possibilities are:
DMA cache coherency
NEC VR4xxxs have no bus-snoop function. So
cache-coherency must be maintaind by software.
(or use KSEG1 access)
But I remember linux-2.4.18 of usb-ohci.c doesn't have
this problem.
Read/write cycle order
Read/write cycle order of CPU instruction level is
guaranteed at bus level?
( Or at assembler level, the sequent instruction is
re-ordered ? )
Newer version of usb-ohci.c has some wmb() funtions.
It synchronizes read/write order.
I got similar errors on VR4181A with 2.4.18 kernel. VR4181A has
built-in USB OHCI 1.1 host connected internal PCI bus.
To fix this problem, I compared newer usb-ohci.c and put wmb()
corresponded place. It is expaneded as subsequent NOPs. (VR4xxx has
real SYNC instruction.)
Thanks.
_._. __._ _ . ... _ .___ ._. _____ _... ._ _._ _.._. .____ _ . ... _
Kunihiko IMAI
^ permalink raw reply
* Re: [linux-lvm] Unable to mount snapshot
From: Heinz J . Mauelshagen @ 2003-12-19 4:10 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <9BBB7C9EFEF1874BAC4DC204E867EFAF02560DD0@s99mail06>
On Thu, Dec 18, 2003 at 12:06:11PM -0600, Little, Chris wrote:
> don't use snapshot. it sucks and the owners won't answer questions about
> it.
Chris,
what in particular problems do you have with snapshots ?
Regards,
Heinz -- The LVM Guy --
>
> > -----Original Message-----
> > From: John Craig [mailto:johncraig01@netscape.net]
> > Sent: Thursday, December 18, 2003 11:34 AM
> > To: linux-lvm@sistina.com
> > Subject: [linux-lvm] Unable to mount snapshot
> >
> >
> > Hi,
> >
> > I successfully created a snapshot of an active LV with XFS
> > filesystem,
> > and ldisplay shows it to be operating correctly. However,
> > when I try to
> > mount the snapshot, it says "wrong fs type, bad option, bad
> > superblock
> > on /dev/system/snap or too many mounted file systems"
> >
> > Can anyone help, or shed some light on why this is happening?
> > Is there a
> > workaround?
> >
> > The mount command was "mount -t xfs -o ro /dev/system/snap /mnt/snap"
> >
> > I am running SuSE 9.0 on x86-64, with kernel 2.4.21-149, lvm version
> > 1.0.7(mp-v6). I have a volume group running on 3 raid arrays,
> > each 0.9
> > TB, for a total of 2.7 TB. It has 2 active LVs, one of them 2 TB, and
> > the other 500GB, leaving about 249GB unallocated. I created
> > the snapshot
> > with:
> >
> > lvcreate -L 200G -s -n snap /dev/system/adsdata
> >
> > As I said, the snapshot seems to be working correctly, but
> > when I bring
> > up the LVM tool in YAST, it shows the original LV, with
> > capacity 1.9 TB,
> > mounted, and the snapshot with a capacity of 1.9TB,
> > unmounted. When I
> > try to set the mount point for the snapshot, it says the capacity is
> > wrong, it needs to be <= 249GB. In other words, it seems to
> > be treating
> > it as if it were a regular LV, not a snapshot..
> >
> > The listing of lvdisplay is:
> > --- Logical volume ---
> > LV Name /dev/system/snap
> > VG Name system
> > LV Write Access read only
> > LV snapshot status active destination for /dev/system/adsdata
> > LV Status available
> > LV # 3
> > # open 0
> > LV Size 2 TB
> > Current LE 16383
> > Allocated LE 16383
> > snapshot chunk size 64 KB
> > Allocated to snapshot 16.66% [33.29 GB/199.90 GB]
> > Allocated to COW-table 100 MB
> > Allocation next free
> > Read ahead sectors 1024
> > Block device 58:2
> >
> >
> >
> >
> > _______________________________________________
> > linux-lvm mailing list
> > linux-lvm@sistina.com
> > http://lists.sistina.com/mailman/listinfo/linux-lvm
> > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
> >
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf
Germany
Mauelshagen@Sistina.com +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply
* Re: Catching NForce2 lockup with NMI watchdog
From: Ross Dickson @ 2003-12-19 4:06 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: george, linux-kernel
In-Reply-To: <Pine.LNX.4.55.0312181347540.23601@jurand.ds.pg.gda.pl>
On Friday 19 December 2003 00:04, Maciej W. Rozycki wrote:
> On Thu, 18 Dec 2003, Ross Dickson wrote:
>
> > Here is where to find Intel's MP arch spec Maceij mentions.
> > I had to find it recently wrt nforce2 issues
> >
> > http://www.intel.com/design/pentium/datashts/24201606.pdf
> >
> > Section 3.6.1 Apic Architecture is relevant
> > particularly
> > Section 3.6.2.2 Virtual Wire Mode
>
> BTW, I have revision 1.1 as well in case anyone was interested in the
> differences.
Yes please if it is forwardable or downloadable.
>
> > I would like to add a footnote to highlight a potential gotcha as I
> > understand it.
> >
> > To clarify, the xt pic 8259A does not in itself have a transparent mode
> > as would a logic buffer or inverter. It always needs inta cycles to
> > function. In PIC mode it is wired to processor pins as per old 8086 and
> > original cpu architecture provides the inta cycles to it (bypasses apic,
> > apic seems off).
>
> It does have such a mode. ;-) You just have not to ack a pending
> interrupt -- if a request goes away, the INT output gets deasserted as
> well. We are super cautious though and we reprogram the 8259A into the
> AEOI mode to prevent a lockup in case INTA cycles escape to the 8259A
> (which is theoretically possible for a broken design of an i82489DX-based
> system). See the 8259A datasheet for details.
>
I believe what you have written because you say it is how the code works.
I take it you mean that the INT is either never latched? or only latched with IS bit
after receipt of first INTA?
It is not obvious in 8259A Datasheet published in Intel Microsystem Components
Handbook Volume 1 1983 nor in datasheet December 1988.
I note the data sheet is almost silent on the topic of INT behaviour without
INTA cycle.
Almost, as the WAVEFORMS diagrams which have INT displayed only
show it in conjunction with the INTA and under said diagram I read
NOTES: Interrupt output must remain HIGH at least until leading edge of first
INTA.
implying it can go low for some reason?
And the,
1. Cycle 1 in iAPX 86 , ....
Only indicates its trailing edge is synchrouous with the machine cycle.
Figure 10 in the data sheet does not help either as when the IR goes low it has
a LATCH* ARMED notation which I took to mean the INT output was then
latched.
I now think it was referring to the transparent D type latch "REQUEST LATCH"
in the priority cell diagram but I cannot see a footnote to the *.
Could you please point me to the document where it is made clear? It may be
in the i82489DX docs as I do not have them or in a later 8259A data sheet
revision?
Thanks,
Ross.
> > I certainly agree with Marceij's comments that mixed mode of having 8254 PIT
> > routed via the 8259A was never meant to occur alongside ioapic handling of
> > the other interrupts. It is very problematic not to mention confusing.
>
> Well, the true "mixed mode", i.e. where certain interrupts are delivered
> as I/O APIC (either LoPri or Fixed) interrupts and others are routed
> through an 8259A controller and delivered as ExtINTA interrupts was
> specifically designed to work since the i8248DX APIC. What wasn't
> designed but works by the properties of the 8259A PIC is the transparent
> "through-8259A" mode.
Clarified thanks.
>
> Maciej
>
> --
> + Maciej W. Rozycki, Technical University of Gdansk, Poland +
> +--------------------------------------------------------------+
> + e-mail: macro@ds2.pg.gda.pl, PGP key available +
>
>
>
^ permalink raw reply
* auto load modules
From: Brian Walker @ 2003-12-19 3:56 UTC (permalink / raw)
To: linux-kernel
Hello. I've just upgraded to 2.6.0 from 2.6.0-test6. When I boot my
system, modules that used to load automatically like those for my
soundcard,bttv, and serial ports(aka /dev/ttyS*) are no longer loading.
I've gone as far as upgrading to module-init-tools-0.9.15-pre4 but
nothing makes these modules load automatically anymore. Any ideas?
Brian
^ permalink raw reply
* Re: SCSI in a post 2.6.0 world
From: Jeff Garzik @ 2003-12-19 3:52 UTC (permalink / raw)
To: Andre Hedrick; +Cc: James Bottomley, SCSI Mailing List
In-Reply-To: <Pine.LNX.4.10.10312181320100.7879-100000@master.linux-ide.org>
Andre Hedrick wrote:
> idea and you explode in a fever to change the world. I agree of the need,
> I just have concern for actually deployment with out a dual path for
> testing.
Not change the world, just update it a bit :)
I fully intend to leverage existing -tested- SCSI code.
Jeff
^ permalink raw reply
* [PATCH][2.6] add #define for clock of VRC4173
From: Yoichi Yuasa @ 2003-12-19 3:49 UTC (permalink / raw)
To: Ralf Baechle; +Cc: yuasa, linux-mips
Hello Ralf,
I made the patch for vrc4173.h.
It add #define for clock of VRC4173.
This patch exists for HEAD of linux-mips.org CVS.
Please apply this patch.
Yoichi
diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/vrc4173.h linux/include/asm-mips/vr41xx/vrc4173.h
--- linux-orig/include/asm-mips/vr41xx/vrc4173.h 2003-11-25 15:29:27.000000000 +0900
+++ linux/include/asm-mips/vr41xx/vrc4173.h 2003-12-19 12:29:25.000000000 +0900
@@ -72,6 +72,19 @@
/*
* Clock Mask Unit
*/
+#define VRC4173_PIU_CLOCK 0x0001
+#define VRC4173_KIU_CLOCK 0x0002
+#define VRC4173_AIU_CLOCK 0x0004
+#define VRC4173_PS2CH1_CLOCK 0x0008
+#define VRC4173_PS2CH2_CLOCK 0x0010
+#define VRC4173_USBU_PCI_CLOCK 0x0020
+#define VRC4173_CARDU1_PCI_CLOCK 0x0040
+#define VRC4173_CARDU2_PCI_CLOCK 0x0080
+#define VRC4173_AC97U_PCI_CLOCK 0x0100
+#define VRC4173_USBU_48MHz_CLOCK 0x0400
+#define VRC4173_EXT_48MHz_CLOCK 0x0800
+#define VRC4173_48MHz_CLOCK 0x1000
+
extern void vrc4173_clock_supply(u16 mask);
extern void vrc4173_clock_mask(u16 mask);
^ 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.