* Re: Cset 1.1490.4.201 - dasd naming
From: Martin Schwidefsky @ 2004-01-27 8:52 UTC (permalink / raw)
To: Pete Zaitcev; +Cc: laroche, linux-kernel, zaitcev
Hi Pete,
> In a recent changeset in Linus' tree, there's your diff which blows up
> the dasd naming scheme, with the comment:
> - Change dasd names from "dasdx" to "dasd_<busid>_".
We plan to do this for tape and other ccw devices as well (where applicable).
> This breaks mkinitrd, nash, and mount by label (not to mention every
> zipl.conf out there, because root= aliases to /sys/block/%s).
> Would you please explain what exactly you were thinking when you
> submitted that patch?
The reason for this change is the requirement to have persistent device
names. The /dev/dasdxyz naming schema heavily depends on the order in
which the device are added. Not good for persistent names. This change
affects four things: 1) the internal name, 2) the name of the sysfs
directory, 3) the root= parameter and 4) the hotplug events for dasd
devices.
blue skies,
Martin
Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH
Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247
E-Mail: schwidefsky@de.ibm.com
^ permalink raw reply
* Re: RE: preparing toshiba_acpi driver release
From: Stefan Seyfried @ 2004-01-27 8:54 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <BF1FE1855350A0479097B3A0D2A80EE0CC8A54-N2PTB0HCzHJF3Yvz3xaN/VDQ4js95KgL@public.gmane.org>
On Mon, Jan 26, 2004 at 02:29:02PM -0500, Brown, Len wrote:
> probably brightness control has some power savings benefits too -- maybe
> somebody on the list has numbers for screen power consumption?
my Asus L2400D with cpufrequency down to 500 MHz, machine is idle (but
connected to USB keyboard/mouse and network).
max. brightness (level 15):
charging state: discharging
present rate: 677 mA
min. brightness (level 1, there is also 0 but then i can't read anything :-)
charging state: discharging
present rate: 557 mA
medium brightness (level 7, this is actually useable)
charging state: discharging
present rate: 597 mA
and just for the record: maximum brightness and cpufreq to 1200 MHz:
charging state: discharging
present rate: 1437 mA
This is no scientific measurement since the machine is not really idle (i'm
writing this mail now :-) and the battery is a blatant liar (if the machine
would draw as little current as /proc/acpi/.../state tells me, it would have
to last twice as long, but it doesnt. So either it lies about capacity or
about current), but it is something to compare.
And yes, when i'm on the road, i always turn down the display as much as
possible to save battery.
I also made the test with an IBM T23 or something like that about a year ago
with Win2k which gave me even bigger savings from the display backlight
(IIRC about 1400 mA with full brightness and 900 mA with minimal).
--
Stefan Seyfried
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* [Bluez-devel] Windows Port
From: Antony C. Roberts @ 2004-01-27 8:54 UTC (permalink / raw)
To: bluez-devel
Hi,
Is anybody working on a Windows port? I did a lot of the work on
Digianswers Windows stack (certainly the inovator back in the day) and I
would passionately like to see the current lack of BT support in Windows
resolved.
So if there are any porting projects in progress, please let me know.
Regards,
Antony C. Roberts.
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply
* Re: [patch] 2.6.1-mm5 compile do not use shared extable code for
From: Paul Mackerras @ 2004-01-27 8:56 UTC (permalink / raw)
To: davidm; +Cc: Andrew Morton, Jes Sorensen, linux-kernel, linux-ia64
In-Reply-To: <16405.41953.344071.456754@napali.hpl.hp.com>
David Mosberger writes:
> How about the attached one? It will touch memory more when moving an
> element down, but we're talking about exception tables here, and I
> don't think module loading time would be affected in any noticable
> fashion.
Hmmm... Stylistically I much prefer to pick up the new element,
move the others up and just drop the new element in where it should
go, rather than doing swap, swap, swap down the list.
Also, I don't think there is enough code there to be worth the bother
of trying to abstract the generic routine so you can plug in different
compare and move-element routines. The whole sort routine is only 16
lines of code, after all. Why not just have an ia64-specific version
of sort_extable? That's what I thought you would do.
Regards,
Paul.
^ permalink raw reply
* Re: More exports for dasd in 2.6
From: Martin Schwidefsky @ 2004-01-27 8:56 UTC (permalink / raw)
To: Pete Zaitcev; +Cc: linux-kernel
Hi Pete,
> here's a little patch to add two more exports, based on my tests.
I already added these two to our tree. But thanks anyway.
blue skies,
Martin
Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH
Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247
E-Mail: schwidefsky@de.ibm.com
^ permalink raw reply
* Re: PPC KGDB changes and some help?
From: Amit S. Kale @ 2004-01-27 8:59 UTC (permalink / raw)
To: Tom Rini; +Cc: Powerpc Linux, Linux Kernel, KGDB bugreports, George Anzinger
In-Reply-To: <20040126213255.GC32525@stop.crashing.org>
On Tuesday 27 Jan 2004 3:02 am, Tom Rini wrote:
> On Wed, Jan 21, 2004 at 12:21:28PM -0700, Tom Rini wrote:
> > On Wed, Jan 21, 2004 at 11:42:17AM -0700, Tom Rini wrote:
> > > On Wed, Jan 21, 2004 at 10:23:12PM +0530, Amit S. Kale wrote:
> > > > Hi,
> > > >
> > > > Here it is: ppc kgdb from timesys kernel is available at
> > > > http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.1.0.tar.bz2
> > > >
> > > > This is my attempt at extracting kgdb from TimeSys kernel. It works
> > > > well in TimeSys kernel, so blame me if above patch doesn't work.
> > >
> > > Okay, here's my first patch against this.
> >
> > And dependant upon this is a patch to fixup the rest of the common PPC
> > code, as follows:
>
> Relative to this, due to the PPC changes is the following:
>
> - In kgdb_handle_exception, memset remcomOutBuffer twice, instead of
> continiously throwing in NULLs around.
Good.
> - Remove a KERN_CRIT from the printk while waiting for kgdb to connect
> (it's not needed there).
It's needed for kgdb over ethernet. At present the ethernet comes up really
late. At that point syslogd has taken over printing of kernel messages,
KERN_CRIT ensures that a user sees that message regardless of the syslogd
configuratio.
> - Switch the initial packet from an 'S' packet (followed by a p for the
> thread ID) to a 'T' packet.
That's also good.
>
> This is tested on PPC and i386 (lightly).
>
> include/asm-i386/kgdb.h | 4 ++
> include/asm-ppc/kgdb.h | 3 +
> include/asm-x86_64/kgdb.h | 4 ++
> kernel/kgdbstub.c | 70
> ++++++++++++++++++++++------------------------ 4 files changed, 45
> insertions(+), 36 deletions(-)
>
> --- 1.1/include/asm-i386/kgdb.h Wed Jan 21 10:13:15 2004
> +++ edited/include/asm-i386/kgdb.h Mon Jan 26 12:15:22 2004
> @@ -43,6 +43,10 @@
> _GS /* 15 */
> };
>
> +#define PC_REGNUM _PC /* Program Counter */
> +#define SP_REGNUM _ESP /* Stack Pointer */
> +#define PTRACE_PC eip /* Program Counter, in ptrace regs. */
> +
> #define BREAKPOINT() asm(" int $3");
> #define BREAK_INSTR_SIZE 1
>
> --- 1.5/include/asm-ppc/kgdb.h Wed Jan 21 12:21:23 2004
> +++ edited/include/asm-ppc/kgdb.h Mon Jan 26 12:16:39 2004
> @@ -19,6 +19,9 @@
> #define NUMREGBYTES (MAXREG * sizeof(int))
> #define BUFMAX ((NUMREGBYTES * 2) + 512)
> #define OUTBUFMAX ((NUMREGBYTES * 2) + 512)
> +#define PC_REGNUM 64
> +#define SP_REGNUM 1
> +#define PTRACE_PC nip /* Program Counter, in ptrace regs. */
> #define BREAKPOINT() asm(".long 0x7d821008") /* twge r2, r2 */
>
> /* Things specific to the gen550 backend. */
> --- 1.1/include/asm-x86_64/kgdb.h Wed Jan 21 10:13:16 2004
> +++ edited/include/asm-x86_64/kgdb.h Mon Jan 26 12:16:15 2004
> @@ -44,6 +44,10 @@
> _PS,
> _LASTREG=_PS };
>
> +#define PC_REGNUM _PC /* Program Counter */
> +#define SP_REGNUM _RSP /* Stack Pointer */
> +#define PTRACE_PC rip /* Program Counter, in ptrace regs. */
> +
> /* Number of bytes of registers. */
> #define NUMREGBYTES (_LASTREG*8)
>
> --- 1.2/kernel/kgdbstub.c Wed Jan 21 12:21:23 2004
> +++ edited/kernel/kgdbstub.c Mon Jan 26 12:17:02 2004
> @@ -615,6 +615,9 @@
> * need one here */
> procindebug[smp_processor_id()] = 1;
>
> + /* Clear the out buffer. */
> + memset(remcomOutBuffer, 0, sizeof(remcomOutBuffer));
> +
> /* Master processor is completely in the debugger */
> if (kgdb_ops->post_master_code)
> kgdb_ops->post_master_code(linux_regs, exVector, err_code);
> @@ -624,9 +627,7 @@
> if(remcomInBuffer[0] == 'H' && remcomInBuffer[1] =='c') {
> remove_all_break();
> atomic_set(&kgdb_killed_or_detached, 0);
> - remcomOutBuffer[0] = 'O';
> - remcomOutBuffer[1] = 'K';
> - remcomOutBuffer[2] = 0;
> + strcpy(remcomOutBuffer, "OK");
> }
> else
> return 1;
> @@ -634,13 +635,25 @@
> else {
>
> /* reply to host that an exception has occurred */
> - remcomOutBuffer[0] = 'S';
> - remcomOutBuffer[1] = hexchars[signo >> 4];
> - remcomOutBuffer[2] = hexchars[signo % 16];
> - remcomOutBuffer[3] = 'p';
> -
> + ptr = remcomOutBuffer;
> + *ptr++ = 'T';
> + *ptr++ = hexchars[(signo >> 4) % 16];
> + *ptr++ = hexchars[signo % 16];
> + *ptr++ = hexchars[(PC_REGNUM >> 4) % 16];
> + *ptr++ = hexchars[PC_REGNUM % 16];
> + *ptr++ = ':';
> + ptr = kgdb_mem2hex((char *)&linux_regs->PTRACE_PC, ptr, 4, 0);
> + *ptr++ = ';';
> + *ptr++ = hexchars[SP_REGNUM >> 4];
> + *ptr++ = hexchars[SP_REGNUM & 0xf];
> + *ptr++ = ':';
> + ptr = kgdb_mem2hex(((char *)linux_regs) + SP_REGNUM * 4, ptr,
> + 4, 0);
> + *ptr++ = ';';
> + ptr += strlen(strcpy(ptr, "thread:"));
> int_to_threadref(&thref, shadow_pid(current->pid));
> - *pack_threadid(remcomOutBuffer + 4, &thref) = 0;
> + ptr = pack_threadid(ptr, &thref);
> + *ptr++ = ';';
> }
> putpacket(remcomOutBuffer, 0);
> kgdb_connected = 1;
> @@ -651,8 +664,10 @@
> while (1) {
> int bpt_type = 0;
> error = 0;
> - remcomOutBuffer[0] = 0;
> - remcomOutBuffer[1] = 0;
> +
> + /* Clear the out buffer. */
> + memset(remcomOutBuffer, 0, sizeof(remcomOutBuffer));
> +
> getpacket(remcomInBuffer);
>
> #if KGDB_DEBUG
> @@ -666,7 +681,6 @@
> remcomOutBuffer[0] = 'S';
> remcomOutBuffer[1] = hexchars[signo >> 4];
> remcomOutBuffer[2] = hexchars[signo % 16];
> - remcomOutBuffer[3] = 0;
> break;
>
> case 'g': /* return the value of the CPU registers */
> @@ -764,9 +778,7 @@
> * continue.
> */
> case 'D':
> - remcomOutBuffer[0] = 'O';
> - remcomOutBuffer[1] = 'K';
> - remcomOutBuffer[2] = '\0';
> + strcpy(remcomOutBuffer, "OK");
> remove_all_break();
> putpacket(remcomOutBuffer, 0);
> kgdb_connected = 0;
> @@ -804,19 +816,16 @@
> i++;
> }
> }
> - *(--ptr) = '\0';
> break;
>
> case 'C':
> /* Current thread id */
> - remcomOutBuffer[0] = 'Q';
> - remcomOutBuffer[1] = 'C';
> + strcpy(remcomOutBuffer, "QC");
>
> threadid = shadow_pid(current->pid);
>
> int_to_threadref(&thref, threadid);
> pack_threadid(remcomOutBuffer + 2, &thref);
> - remcomOutBuffer[18] = '\0';
> break;
>
> case 'E':
> @@ -829,7 +838,6 @@
> case 'T':
> if (memcmp(remcomInBuffer+1, "ThreadExtraInfo,",16))
> {
> - remcomOutBuffer[0] = 0;
> strcpy(remcomOutBuffer, "E05");
> break;
> }
> @@ -872,14 +880,11 @@
> thread = getthread(linux_regs, threadid);
> if (!thread && threadid > 0) {
> remcomOutBuffer[0] = 'E';
> - remcomOutBuffer[1] = '\0';
> break;
> }
> kgdb_usethread = thread;
> kgdb_usethreadid = threadid;
> - remcomOutBuffer[0] = 'O';
> - remcomOutBuffer[1] = 'K';
> - remcomOutBuffer[2] = '\0';
> + strcpy(remcomOutBuffer, "OK");
> break;
>
> case 'c':
> @@ -892,14 +897,11 @@
> thread = getthread(linux_regs, threadid);
> if (!thread && threadid > 0) {
> remcomOutBuffer[0] = 'E';
> - remcomOutBuffer[1] = '\0';
> break;
> }
> kgdb_contthread = thread;
> }
> - remcomOutBuffer[0] = 'O';
> - remcomOutBuffer[1] = 'K';
> - remcomOutBuffer[2] = '\0';
> + strcpy(remcomOutBuffer, "OK");
> break;
> }
> break;
> @@ -909,14 +911,10 @@
> ptr = &remcomInBuffer[1];
> kgdb_hexToLong(&ptr, &threadid);
> thread = getthread(linux_regs, threadid);
> - if (thread) {
> - remcomOutBuffer[0] = 'O';
> - remcomOutBuffer[1] = 'K';
> - remcomOutBuffer[2] = '\0';
> - } else {
> + if (thread)
> + strcpy(remcomOutBuffer, "OK");
> + else
> remcomOutBuffer[0] = 'E';
> - remcomOutBuffer[1] = '\0';
> - }
> break;
> case 'z':
> case 'Z':
> @@ -1127,7 +1125,7 @@
> */
> printk(KERN_CRIT "Waiting for connection from remote gdb... ");
> breakpoint() ;
> - printk(KERN_CRIT "Connected.\n");
> + printk("Connected.\n");
> }
>
> #ifdef CONFIG_KGDB_CONSOLE
>
> --
> Tom Rini
> http://gate.crashing.org/~trini/
>
> ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
--
Amit Kale
EmSysSoft (http://www.emsyssoft.com)
KGDB: Linux Kernel Source Level Debugger (http://kgdb.sourceforge.net)
^ permalink raw reply
* Re: [PATCH] 2.6.2-rc2 - MPT Fusion driver 3.00.02 update
From: Douglas Gilbert @ 2004-01-27 8:56 UTC (permalink / raw)
To: Jeremy Higdon
Cc: Christoph Hellwig, James Bottomley, Moore, Eric Dean,
SCSI Mailing List
In-Reply-To: <20040127061800.GB429536@sgi.com>
Jeremy Higdon wrote:
> On Mon, Jan 26, 2004 at 07:34:13PM +0000, Christoph Hellwig wrote:
>
>>On Mon, Jan 26, 2004 at 11:05:26AM -0600, James Bottomley wrote:
>>
>>>>I had avoided it due the comments in the code
>>>>from sralston and pdelaney about sg interface
>>>>gererating wrong direction in some cases.
>>>
>>>If you find a problem, I'll fix the generic code...
>>
>>I think it's just very old comments. We had such a problem in early 2.4
>>kernels, but it has been fixed for ages. If it wasn't most of the scsi
>>drivers would have a big problem.
>
>
> Aren't there three interfaces for sg, or did the early ones go away
> in 2.6? I recall that we ran into trouble with sg setting the
> direction incorrectly in 2.4 kernels when using older interface,
> I think.
Jeremy,
I can't see any such report in my changelogs for the sg
driver during the lk 2.4 series. What was difficult with
the older sg interface (sg_header based) was setting the
command length as this was "guessed" from the first 3 bits
of the opcode (SCSI_IOCTL_SEND_COMMAND ioctl still does this).
Doug Gilbert
^ permalink raw reply
* Re: 2.6.2-rc1 / ACPI sleep / irqbalance / kirqd / pentium 4 HT problems on Uniwill N258SA0
From: Pavel Machek @ 2004-01-27 8:39 UTC (permalink / raw)
To: Huw Rogers; +Cc: linux-kernel, linux-laptop
In-Reply-To: <20040124233749.5637.COUNT0@localnet.com>
Hi!
> irqbalance just locks up the machine totally, hard power-off needed, no
> traces in the logs. Probably some issue (race?) with it writing to
> /proc/irq/X/smp_affinity. And how is irqbalance supposed to play with
> kirqd anyway? Grepping this list and others doesn't give any kind of an
> answer. But disabling it gives all interrupts to cpu0 (looking at
> /proc/interrupts). kirqd apparently only balances between CPU packages,
> not between HT siblings (info gleaned from this list).
>
> Anyway, sleep/suspend/standby functionality (important to most laptop
> users, need to close the lid and go): This checkin to
> kernel/power/main.c seems to disable suspend with SMP (!?):
>
> --- 1.3/kernel/power/main.c Sat Jan 24 20:44:47 2004
> +++ 1.4/kernel/power/main.c Sat Jan 24 20:44:47 2004
> @@ -172,6 +172,12 @@
> if (down_trylock(&pm_sem))
> return -EBUSY;
>
> + /* Suspend is hard to get right on SMP. */
> + if (num_online_cpus() != 1) {
> + error = -EPERM;
> + goto Unlock;
> + }
> +
> if ((error = suspend_prepare(state)))
> goto Unlock;
>
> ... which, given the prevalence of hyperthreaded CPUs on laptops, is
> fighting a trend. I backed out the above with a #if 0 then tried echo -n
> 1>/proc/acpi/sleep again. This time I got:
Well, no sleep developers have SMP or HT machines, AFAICT.
If you back that out... well you are on your own.
> A lot of effort is going into swsusp/pmdisk - but a lot of laptop users
> prefer S1 to S4, as it's faster and more reliable. It'd be nice to see a
> simpler "spin down the hard drive, reduce CPU clock speed to a minimum,
> and power down display/ether/wireless/usb/PCMCIA" working ahead of
> hibernation.
As far as I can see, noone is interested in S1. If you want to help
with it... [There's no need to stop tasks/stop devices on non-broken
hardware. Unfortunately there's a lot of broken hw out there, so I'm
not sure we can do it by default.]
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
^ permalink raw reply
* Re: PPC KGDB changes and some help?
From: Amit S. Kale @ 2004-01-27 9:05 UTC (permalink / raw)
To: Tom Rini, George Anzinger; +Cc: Powerpc Linux, Linux Kernel, KGDB bugreports
In-Reply-To: <20040126220651.GE32525@stop.crashing.org>
On Tuesday 27 Jan 2004 3:36 am, Tom Rini wrote:
> On Mon, Jan 26, 2004 at 01:45:44PM -0800, George Anzinger wrote:
> > Tom Rini wrote:
> > >>There is a real danger of passing signal info back to gdb as it will
> > >> want to try to deliver the signal which is a non-compute in most kgdbs
> > >> in the field. I did put code in the mm-kgdb to do just this, but
> > >> usually the arrival of such a signal (other than SIGTRAP) is the end
> > >> of the kernel. All that is left is to read the tea leaves.
> > >
> > >The gdb I've been testing this with knows better than to try and send a
> > >singal back, so that's not a worry. The motivation behind doing this
> > >however is along the lines of "if it ain't broke, don't remove it". The
> > >original stub was getting all of this information correctly, so why stop
> > >doing it?
> >
> > You sure. If so what gdb? And how does it know? I suppose you could
> > tell it with a script, but then what if one forgets?
>
> GNU gdb 6.0 (MontaVista 6.0-8.0.4.0300532 2003-12-24)
> Copyright 2003 Free Software Foundation, Inc.
> [snip]
>
> [New Thread 289]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 289]
> 0x00000000 in ?? ()
> (gdb) c
> Continuing.
> Can't send signals to this remote system. SIGSEGV not sent.
This is because gdb tries packet "C" first. If that fails, which is the case
with kgdb, it falls back to packet "c". It doesn't need packet "C" for
SIGTRAP as it's used for breakpoints and single stepping and shouldn't be
delivered to a debuggee.
SIGSEGV has to be actually delivered to an application for it to die. A user
has a choice of correcting a bug on the fly and let the application continue
without segfaulting. It can tell gdb to continue the debugee without a
signal. It doesn't apply in case of kernel, so it's not a bug. Kernel anyway
"delivers" the signal, that is, continues with a panic once kgdb returns. We
don't offer a user the choice of correcting a segfault on the fly.
>
> Noting that 0x0 is correct as the code that triggered this was:
> static void (*dummy)(struct pt_regs *regs);
> int drop_kgdb(void) {
> struct pt_regs regs;
> memset(®s, 0, sizeof(regs));
> dummy(®s);
>
> return 0;
> }
> module_init(drop_kgdb);
>
> --
> Tom Rini
> http://gate.crashing.org/~trini/
>
> ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
--
Amit Kale
EmSysSoft (http://www.emsyssoft.com)
KGDB: Linux Kernel Source Level Debugger (http://kgdb.sourceforge.net)
^ permalink raw reply
* [Bluez-users] Getting remote device address & name using obex commands
From: jan d tux @ 2004-01-27 9:07 UTC (permalink / raw)
To: BlueZ Mailing List
Hello to everyone.
Is there an obex command that I can use to get the bluetooth address and
name of a remote device? It is possible with hci commands but I would
like to use obex commands if it is possible.
What Im trying to do is run the obexserver (from frasunek) and get the
sender's address and name.
Any help would be appreciated.
Thanks
:)
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply
* Re: [patch] 2.6.1-mm5 compile do not use shared extable code for ia64
From: Paul Mackerras @ 2004-01-27 8:56 UTC (permalink / raw)
To: davidm; +Cc: Andrew Morton, Jes Sorensen, linux-kernel, linux-ia64
In-Reply-To: <16405.41953.344071.456754@napali.hpl.hp.com>
David Mosberger writes:
> How about the attached one? It will touch memory more when moving an
> element down, but we're talking about exception tables here, and I
> don't think module loading time would be affected in any noticable
> fashion.
Hmmm... Stylistically I much prefer to pick up the new element,
move the others up and just drop the new element in where it should
go, rather than doing swap, swap, swap down the list.
Also, I don't think there is enough code there to be worth the bother
of trying to abstract the generic routine so you can plug in different
compare and move-element routines. The whole sort routine is only 16
lines of code, after all. Why not just have an ia64-specific version
of sort_extable? That's what I thought you would do.
Regards,
Paul.
^ permalink raw reply
* [PATCH] Incorrect value for SIGRTMAX, MIPS nonsense removed, timer_gettime fix
From: George Anzinger @ 2004-01-27 9:19 UTC (permalink / raw)
To: eric.piel; +Cc: akpm, Corey Minyard, linux-kernel
In-Reply-To: <1074979873.4012e421714b1@mailetu.utc.fr>
[-- Attachment #1: Type: text/plain, Size: 807 bytes --]
The attached patch does the following:
Removes C++ comment in favor of C style.
Removes the special treatment for MIPS SIGEV values. We only require (and error
if this fails) that the SIGEV_THREAD_ID value not share bits with the other
SIGEV values. Note that mips has yet to define this value so when they do...
Corrects the check for the signal range to be from 1 to SIGRTMAX inclusive.
Adds a check to verify that kmem_cache_alloc() actually returned a timer, error
if not.
Fixes a bug in timer_gettime() where the incorrect value was returned if a
signal was pending on the timer OR the timer was a SIGEV_NONE timer.
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
[-- Attachment #2: posix-timers-2.6.1-1.0.patch --]
[-- Type: text/plain, Size: 5206 bytes --]
--- linux-2.6.1-org/kernel/posix-timers.c 2003-12-10 17:10:42.000000000 -0800
+++ linux/kernel/posix-timers.c 2004-01-27 01:10:58.000000000 -0800
@@ -2,8 +2,26 @@
* linux/kernel/posix_timers.c
*
*
- * 2002-10-15 Posix Clocks & timers by George Anzinger
- * Copyright (C) 2002 by MontaVista Software.
+ * 2002-10-15 Posix Clocks & timers
+ * by George Anzinger george@mvista.com
+ *
+ * Copyright (C) 2002 2003 by MontaVista Software.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or (at
+ * your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ * MontaVista Software | 1237 East Arques Avenue | Sunnyvale | CA 94085 | USA
*/
/* These are all the functions necessary to implement
@@ -33,7 +51,7 @@
result; })
#endif
-#define CLOCK_REALTIME_RES TICK_NSEC // In nano seconds.
+#define CLOCK_REALTIME_RES TICK_NSEC /* In nano seconds. */
static inline u64 mpy_l_X_l_ll(unsigned long mpy1,unsigned long mpy2)
{
@@ -82,17 +100,15 @@
# define timer_active(tmr) BARFY // error to use outside of SMP
# define set_timer_inactive(tmr) do { } while (0)
#endif
-
/*
- * For some reason mips/mips64 define the SIGEV constants plus 128.
- * Here we define a mask to get rid of the common bits. The
- * optimizer should make this costless to all but mips.
- * Note that no common bits (the non-mips case) will give 0xffffffff.
- */
-#define MIPS_SIGEV ~(SIGEV_NONE & \
- SIGEV_SIGNAL & \
- SIGEV_THREAD & \
- SIGEV_THREAD_ID)
+ * we assume that the new SIGEV_THREAD_ID shares no bits with the other
+ * SIGEV values. Here we put out an error if this assumption fails.
+ */
+#if SIGEV_THREAD_ID != (SIGEV_THREAD_ID & \
+ ~(SIGEV_SIGNAL | SIGEV_NONE | SIGEV_THREAD))
+#error "SIGEV_THREAD_ID must not share bit with other SIGEV values!"
+#endif
+
#define REQUEUE_PENDING 1
/*
@@ -301,7 +317,7 @@
if (timr->it_incr)
timr->sigq->info.si_sys_private = ++timr->it_requeue_pending;
- if (timr->it_sigev_notify & SIGEV_THREAD_ID & MIPS_SIGEV)
+ if (timr->it_sigev_notify & SIGEV_THREAD_ID )
ret = send_sigqueue(timr->it_sigev_signo, timr->sigq,
timr->it_process);
else
@@ -338,14 +354,14 @@
{
struct task_struct *rtn = current;
- if ((event->sigev_notify & SIGEV_THREAD_ID & MIPS_SIGEV) &&
+ if ((event->sigev_notify & SIGEV_THREAD_ID ) &&
(!(rtn = find_task_by_pid(event->sigev_notify_thread_id)) ||
- rtn->tgid != current->tgid))
+ rtn->tgid != current->tgid ||
+ (event->sigev_notify & ~SIGEV_THREAD_ID) != SIGEV_SIGNAL))
return NULL;
- if ((event->sigev_notify & ~SIGEV_NONE & MIPS_SIGEV) &&
- event->sigev_signo &&
- ((unsigned) (event->sigev_signo > SIGRTMAX)))
+ if (((event->sigev_notify & ~SIGEV_THREAD_ID) != SIGEV_NONE) &&
+ ((unsigned int) (event->sigev_signo - 1) >= SIGRTMAX))
return NULL;
return rtn;
@@ -365,6 +381,8 @@
{
struct k_itimer *tmr;
tmr = kmem_cache_alloc(posix_timers_cache, GFP_KERNEL);
+ if (!tmr)
+ return tmr;
memset(tmr, 0, sizeof (struct k_itimer));
tmr->it_id = (timer_t)-1;
if (unlikely(!(tmr->sigq = sigqueue_alloc()))) {
@@ -586,14 +604,18 @@
posix_get_now(&now);
- if (expires && (timr->it_sigev_notify & SIGEV_NONE) && !timr->it_incr &&
- posix_time_before(&timr->it_timer, &now))
+ if (expires &&
+ ((timr->it_sigev_notify & ~SIGEV_THREAD_ID) == SIGEV_NONE) &&
+ !timr->it_incr &&
+ posix_time_before(&timr->it_timer, &now))
timr->it_timer.expires = expires = 0;
if (expires) {
if (timr->it_requeue_pending & REQUEUE_PENDING ||
- (timr->it_sigev_notify & SIGEV_NONE))
+ (timr->it_sigev_notify & ~SIGEV_THREAD_ID) == SIGEV_NONE) {
while (posix_time_before(&timr->it_timer, &now))
posix_bump_timer(timr);
+ expires = timr->it_timer.expires;
+ }
else
if (!timer_pending(&timr->it_timer))
expires = 0;
@@ -804,7 +826,7 @@
* equal to jiffies, so the timer notify function is called directly.
* We do not even queue SIGEV_NONE timers!
*/
- if (!(timr->it_sigev_notify & SIGEV_NONE)) {
+ if (!((timr->it_sigev_notify & ~SIGEV_THREAD_ID) == SIGEV_NONE)) {
if (timr->it_timer.expires == jiffies)
timer_notify_task(timr);
else
@@ -967,9 +989,6 @@
* if we are interrupted since we don't take lock that will stall us or
* any other cpu. Voila, no irq lock is needed.
*
- * Note also that the while loop assures that the sub_jiff_offset
- * will be less than a jiffie, thus no need to normalize the result.
- * Well, not really, if called with ints off :(
*/
static u64 do_posix_clock_monotonic_gettime_parts(
^ permalink raw reply
* linux-2.6.1 x86_64 : STACK_TOP and text/data
From: dada1 @ 2004-01-27 9:25 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <OFCE30A640.024A04A1-ONC1256E28.003023EA-C1256E28.0030BF4E@de.ibm.com>
Hi all
Anybody knows why STACK_TOP is defined to 0xc0000000 in x86_64 ?
This means that stack allocated variables are all in the first 4GB
quadrant in memory.
As the default virtual addresses of text/data of a programm are in this
same quadrant, some programming errors could be undetected.
(Some programmers could still cast some pointers to 'unsigned int' for
example, and this could 'work')
Tru64 has a different strategy :
Program text starts at 0x120000000
Program data starts at 0x140000000
Stack is just under text, but still not in the first 4GB quadrant.
This way, programmers errors are likely to be detected at dev time.
Another point is that BSS zone (heap) cannot exceed 3GB in x86_64 mode,
since the brk hit the stack.
libc malloc then fallback to use a lot of arenas... suboptimal in terms
of vmas.
Strangely, in ia32 emulation mode, the stack is placed at the 4GB limit !
Thank you
Eric Dumazet
^ permalink raw reply
* Re: [Adeos-main] [PATCH] armnommu compile fix
From: Philippe Gerum @ 2004-01-27 9:29 UTC (permalink / raw)
To: Paul Mundt; +Cc: adeos-main
In-Reply-To: <20040127000022.GA17036@domain.hid>
On Tue, 2004-01-27 at 01:00, Paul Mundt wrote:
> Hi,
>
> The current kernel-2.4/adeos-common/include/asm-armnommu/adeos.h has a broken
> __adeos_clear_irq(). This looks like it was copied from an SMP-able adeos.h
> and cleaned up, with only this one line being left over and subsequently
> causing the build to fail.
>
Indeed it was. Applied, thanks.
> Against current CVS HEAD.
>
> kernel-2.4/adeos-common/include/asm-armnommu/adeos.h | 1 -
> 1 files changed, 1 deletion(-)
>
> Index: kernel-2.4/adeos-common/include/asm-armnommu/adeos.h
> ===================================================================
> RCS file: /cvsroot/adeos/adeos/platforms/linux/kernel-2.4/adeos-common/include/asm-armnommu/adeos.h,v
> retrieving revision 1.20
> diff -u -r1.20 adeos.h
> --- kernel-2.4/adeos-common/include/asm-armnommu/adeos.h 9 Jan 2004 10:06:15 -0000 1.20
> +++ kernel-2.4/adeos-common/include/asm-armnommu/adeos.h 26 Jan 2004 23:59:04 -0000
> @@ -204,7 +204,6 @@
> clear_bit(IPIPE_LOCK_FLAG,&(adp)->irqs[irq].control); \
> (adp)->cpudata[0].irq_hits[irq] = 0; \
> __adeos_clear_pend(adp,irq); \
> - } \
> } while(0)
>
> #define adeos_virtual_irq_p(irq) ((irq) >= IPIPE_VIRQ_BASE && \
>
> ______________________________________________________________________
> _______________________________________________
> Adeos-main mailing list
> Adeos-main@domain.hid
> http://mail.nongnu.org/mailman/listinfo/adeos-main
--
Philippe.
^ permalink raw reply
* [LARTC] RE: LARTC digest, Vol 1 #1558 - 9 msgs
From: Aron Brand @ 2004-01-27 9:30 UTC (permalink / raw)
To: lartc
Hi Roy,
Strange. "kernel will resend then together with new ones" - this is
interesting, since the firewall DOES know how to drop locally generated
packets and the kernel doesn't attempt to retry them. I am not an expert
on this, but I think it might be interesting to check how the firewall
does this. Another option would be to trick the kernel that the packet
has been transmitted, to prevent the immediate retries, while actually
vanishing the packet.
Aron
--__--__--
Message: 8
From: "Roy" <roy@xxx.lt>
To: <rubens@etica.net>
Cc: <lartc@mailman.ds9a.nl>
Subject: Re: [LARTC] NEW imq driver
Date: Tue, 27 Jan 2004 06:42:29 +0200
Seems I was to fast to declare success,
my version is not much more stable than the original one,everything
depends
on dropped packets.
This is even not imq fault afterall, can be prowed in other way also:
atempts to police outgoing trafic it will be ok until you dont touch
localy
generated packets
if you try to drop them you will be sorry, because kernel will resend
then
together with new ones
of cource policer will drop them too, but linux kernel keeps resending
then
thus increasing rate progresively.
I noticed that with my trafic counter. internal trafic grew to enormous
levels 10X more than it can be. In reality there was almost no output at
all.
so DONT USE POLICERS ON EGRESS. on low trafic it is harmless but on
100mb/s
it probably can kill computer (not tested).
Seems imq have similar problem even if driver itself have no leaks
kernel
consumes all resousces on resnending droped packets so that computer
stops
responding
for now I dont have good idea how to fix it so I will try to avoid
localy
generated trafic
so it will me possible to shape ingress and forward, egress will be left
for
real device.
maybe later I will find how fix that
>
> It seems to capture ingress and egress traffic of all interfaces;
wouldn't
> this count packets twice ?
No, ingress is for local and egress for everything so everything should
be
ok (in theory)
> If the machine is doing SNAT or DNAT, what IP addresses would be seen
by
> the qdisc ?
>
I made driver see the final destination address because it is more
usefull
> Rubens
>
>
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* [PATCH] Fine tune the time conversion to eliminate conversion errors.
From: George Anzinger @ 2004-01-27 9:31 UTC (permalink / raw)
To: akpm; +Cc: eric.piel, Corey Minyard, linux-kernel
In-Reply-To: <1074979873.4012e421714b1@mailetu.utc.fr>
[-- Attachment #1: Type: text/plain, Size: 884 bytes --]
Andrew,
The time conversion code is erroring on the side of a bit too small. The
attached patch forces any error to be on the high side. The current code will
convert 1 nanosecond to zero jiffies (standard says that should be 1). It also
is around 1 nanosecond late on each roll to the next jiffie.
I have done some error checks with this patch applied and get the following
errors in PPB ( Parts Per Billion):
HZ nano sec conversion microsecond conversion
1000 315 45
1024 227 40
100 28 317
In all cases the error is on the high side, which means that the final shift
will, most likely, eliminate the error bits.
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
[-- Attachment #2: time.h-2.6.1-1.0.patch --]
[-- Type: text/plain, Size: 1309 bytes --]
--- linux-2.6.1-org/include/linux/time.h 2003-08-11 13:48:55.000000000 -0700
+++ linux/include/linux/time.h 2004-01-27 00:29:12.000000000 -0800
@@ -148,14 +148,14 @@
#endif
#define NSEC_JIFFIE_SC (SEC_JIFFIE_SC + 29)
#define USEC_JIFFIE_SC (SEC_JIFFIE_SC + 19)
-#define SEC_CONVERSION ((unsigned long)((((u64)NSEC_PER_SEC << SEC_JIFFIE_SC))\
- / (u64)TICK_NSEC))
+#define SEC_CONVERSION ((unsigned long)((((u64)NSEC_PER_SEC << SEC_JIFFIE_SC) +\
+ TICK_NSEC -1) / (u64)TICK_NSEC))
-#define NSEC_CONVERSION ((unsigned long)((((u64)1 << NSEC_JIFFIE_SC))\
- / (u64)TICK_NSEC))
+#define NSEC_CONVERSION ((unsigned long)((((u64)1 << NSEC_JIFFIE_SC) +\
+ TICK_NSEC -1) / (u64)TICK_NSEC))
#define USEC_CONVERSION \
- ((unsigned long)((((u64)NSEC_PER_USEC << USEC_JIFFIE_SC)) \
- / (u64)TICK_NSEC))
+ ((unsigned long)((((u64)NSEC_PER_USEC << USEC_JIFFIE_SC) +\
+ TICK_NSEC -1) / (u64)TICK_NSEC))
/*
* USEC_ROUND is used in the timeval to jiffie conversion. See there
* for more details. It is the scaled resolution rounding value. Note
^ permalink raw reply
* Re: Root Drive Mirroring and LVM.
From: Sven Luther @ 2004-01-27 9:32 UTC (permalink / raw)
To: Atro.Tossavainen; +Cc: linuxppc-dev, linux-raid, tas
In-Reply-To: <200401270801.i0R81HdT022197@kruuna.Helsinki.FI>
On Tue, Jan 27, 2004 at 10:01:17AM +0200, Atro Tossavainen wrote:
>
> Sorry about the crossposting.
>
> I wrote on the Yellow Dog Linux list when somebody asked about software
> RAID on YDL about my experiences with it:
>
> >> The one really big gotcha is that the Macintosh partitioning scheme
> >> can't tell the Linux kernel that certain partitions are to be
> >> considered "Linux RAID autodetect" (as in x86 using the DOS partition
> >> table type 0xfd). This means that you can't boot a Mac Linux system
> >> directly from RAID because the kernel won't be able to autostart the
> >> RAID devices. You have to work around this by creating an initial RAM
> >> disk that uses the raidstart command to start your metadevices, then
> >> swaps the initrd out of the way and proceeds to start the real system.
>
> to which Tim Seufert replied on the same list:
>
> > Hmmm. That would seem to be a lack in the Linux RAID code, since the
> > Macintosh partition table has a vastly more flexible partition type
> > field than DOS: instead of a single byte it's a string. It would mean
> > breaking from the convention of using the "Apple_SVR2_UNIX" type for
> > Linux partitions, but that really is just a convention as far as I know.
>
> Perhaps the PPC Linux developers and the Linux RAID developers should
> get together on this and make some decisions so as to make it happen.
Seems ok for me. Also, i guess that there are other partition types,
like the amiga partitition table the pegasos boxes mostly use, which has
a 32bit identifier for partition types. I guess it is the task of the
RAID code to have some per partition type checking for this RAID autodetect
magic.
Friendly,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* MPC8540ADS setup
From: Stefan Nickl @ 2004-01-27 9:36 UTC (permalink / raw)
To: linuxppc-embedded
Hi list,
I have some initial troubles with the MPC8540ADS that
are probably FAQ, but I did not find in the list archives.
1st, whats the correlation between PVR and "Revision"?
My PVR is 0x80200010, the BDI firmware says
Target CPU : MPC8560/8540 Rev.1,
while u-boot/doc/README.mpc85xxads reads:
"MPC85xx Rev 1 Chip, in general you will use a Rev2
chip from Nov.2003. If you still see this definition
while you have a Rev2(and newer) chip,undef this."
So what Rev do I have? Booby traps on the way?
2nd, how to correctly setup the BDI flash access?
bdi-8540>unlock 0xFF000000
# Writing to workspace failed
I've taken the sections from ads8560.cfg that
seem to map L2SRAM for that purpose and
use WORKSPACE 0xf0000000.
Some working [INIT]-Lines?
3rd, some reset-trouble with the BDI.
It seems I have to do
reset run
g
reset run
every time to reset the board, otherwise it stays dead :(
Not necessary on manual reset and powerup.
Thanks,
-- Stefan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: p4_clockmod or speedstep_ich | acpi?
From: Ducrot Bruno @ 2004-01-27 9:39 UTC (permalink / raw)
To: Marcus Grando; +Cc: cpufreq
In-Reply-To: <4015CFE8.1030002@corp.grupos.com.br>
On Tue, Jan 27, 2004 at 12:41:44AM -0200, Marcus Grando wrote:
> Hi,
>
> But why my kernel show this messages, if celeron not support speedstep-ich?
>
> cpufreq: P4/Xeon(TM) CPU On-Demand Clock Modulation available
> cpufreq: Warning: Pentium 4-M detected. The speedstep-ich or acpi cpufreq
> cpufreq: modules offers voltage scaling in addition of frequency
> scaling. You
> cpufreq: should use either one instead of p4-clockmod, if possible.
>
Because this code was added in order to tell people who have a
P4m to take into account the speedstep-ich, etc. Just that
it seems this code is not able to distinguish yet p4m and celerons...
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
^ permalink raw reply
* Re: MAX_PORTS for ftp modules
From: Henrik Nordstrom @ 2004-01-27 9:40 UTC (permalink / raw)
To: Nick Pasich; +Cc: netfilter-devel
In-Reply-To: <20040126211441.GA10833@66.27.62.2>
On Mon, 26 Jan 2004, Nick Pasich wrote:
> I've exhausted the MAX_PORTS limit of 8 for ftp using my own port id.
>
> I'm wondering if there are any repercussions in upping the limit to say,
> 16 in the following modules.
None I know of. But you should be careful to not register any ports wich
is ever used for non-FTP traffic.
Note: TFTP is not the same as FTP, and ipfwadm is only relevant if your
are using ipfwadm and is not related to your question.
Regards
Henrik
^ permalink raw reply
* Re: [patch] Re: Kernels > 2.6.1-mm3 do not boot. - SOLVED
From: Erik Hensema @ 2004-01-27 9:40 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20040125220027.30e8cdf3.akpm@osdl.org>
Andrew Morton (akpm@osdl.org) wrote:
> "John Stoffel" <stoffel@lucent.com> wrote:
>>
>> Sure, the darn thing wouldn't boot, it kept Oopsing with the
>> test_wp_bit oops (that I just posted more details about).
>
> Does this fix the test_wp_bit oops?
>
> --- 25/init/main.c~test_wp_bit-oops-fix 2004-01-25 15:29:53.000000000 -0800
> +++ 25-akpm/init/main.c 2004-01-25 15:30:03.000000000 -0800
> @@ -434,9 +434,9 @@ asmlinkage void __init start_kernel(void
> }
> #endif
> page_address_init();
> + sort_main_extable();
> mem_init();
> kmem_cache_init();
> - sort_main_extable();
> if (late_time_init)
> late_time_init();
> calibrate_delay();
This makes 2.6.2-rc2 boot for me.
--
Erik Hensema <erik@hensema.net>
^ permalink raw reply
* [parisc-linux] error?
From: Naresh Kumar @ 2004-01-27 9:46 UTC (permalink / raw)
To: parisc-linux
[-- Attachment #1: Type: text/plain, Size: 776 bytes --]
Hi,
I noticed in the function 'linux-2.6/drivers/parisc/lba_pci.c:
lba_pat_resources( )' the following lines:
---------------------------------------------------------------
case PAT_GMMIO:
r = &(lba_dev->hba.gmmio_space);
r->name = "LBA GMMIO";
r->start = p->start;
r->end = p->end;
r->flags = IORESOURCE_MEM;
r->parent = r->sibling = r->child = NULL;
break;
lba_dev->gmmio_base = p->start;
break;
case PAT_NPIOP:
printk(KERN_WARNING MODULE_NAME
" range[%d] : ignoring NPIOP (0x%lx)\n",
i, p->start);
break;
-------------------------------------------------------------------
Please note the extra lines after the 'break;'. The version of
'lba_pci.c' is 1.7. Seems to have happened due to oversight.
Thanks,
Naresh.
[-- Attachment #2: Type: text/html, Size: 1159 bytes --]
^ permalink raw reply
* porting sorcerer to udev
From: MALET JL @ 2004-01-27 9:48 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]
hello,
I'm one of the linux sorcerer maintainer and I'm trying to switch
sorcerer to udev (from devfs)
the "spells" (compile/install scripts) are done and everything install fine
hotplug scripts seems to work correctly at least for usb (some strange
error on pci only with 2.6 kernels, some modules aren't loaded but I
haven't investigateted further) : my usb mouse/adaptaters modules are
loaded at boot time....
so this means : 1) pci hosts are detected 2) usb OHCI generate the event
(detection of usbmouse) and hotplug loads the corrects modules :)
BUT :( udev don't work
running the test scripts work correctly (it's awfully long but at least
this create some entries) after i mounted sysfs into /sys (previous
mount point was /sysfs but udev don't work with it)
so I don't understand.....
I readed into the docs and found that udev/hotplug is now
udev/namedev/hotplug/libsysfs but I can't find namedev stuff can it
comes from that?
the link of udev into hotplug.d is correct and have the rights modes
if someone can help.....
[-- Attachment #2: Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply
* Re: Root Drive Mirroring and LVM.
From: Ethan Benson @ 2004-01-27 9:50 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20040127093213.GA10049@iliana>
On Tue, Jan 27, 2004 at 10:32:13AM +0100, Sven Luther wrote:
>
> On Tue, Jan 27, 2004 at 10:01:17AM +0200, Atro Tossavainen wrote:
> >
> > Sorry about the crossposting.
> >
> > I wrote on the Yellow Dog Linux list when somebody asked about software
> > RAID on YDL about my experiences with it:
> >
> > >> The one really big gotcha is that the Macintosh partitioning scheme
> > >> can't tell the Linux kernel that certain partitions are to be
> > >> considered "Linux RAID autodetect" (as in x86 using the DOS partition
> > >> table type 0xfd). This means that you can't boot a Mac Linux system
> > >> directly from RAID because the kernel won't be able to autostart the
> > >> RAID devices. You have to work around this by creating an initial RAM
> > >> disk that uses the raidstart command to start your metadevices, then
> > >> swaps the initrd out of the way and proceeds to start the real system.
> >
> > to which Tim Seufert replied on the same list:
> >
> > > Hmmm. That would seem to be a lack in the Linux RAID code, since the
> > > Macintosh partition table has a vastly more flexible partition type
> > > field than DOS: instead of a single byte it's a string. It would mean
> > > breaking from the convention of using the "Apple_SVR2_UNIX" type for
> > > Linux partitions, but that really is just a convention as far as I know.
> >
> > Perhaps the PPC Linux developers and the Linux RAID developers should
> > get together on this and make some decisions so as to make it happen.
>
> Seems ok for me. Also, i guess that there are other partition types,
> like the amiga partitition table the pegasos boxes mostly use, which has
> a 32bit identifier for partition types. I guess it is the task of the
> RAID code to have some per partition type checking for this RAID autodetect
> magic.
in general we need to stop using Apple_* types for our partitions,
apple clearly documents that the entire Apple_* namespace is reserved
solely for Apple use, and 3rd party developers must use something,
anything else for thier partitions.
the trick is coming up with a generic enough and sensible enough
naming convention. (i think its quite silly to include specific
filesystem names in partition types, and really it seems silly to
specify "Linux" for filesystems which can and are used by OSes other
then "Linux" (ext2 is used in Hurd for example)).
--
Ethan Benson
http://www.alaska.net/~erbenson/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* 1.0.2 release
From: Jaroslav Kysela @ 2004-01-27 9:51 UTC (permalink / raw)
To: ALSA development; +Cc: ALSA Announce
Hello all,
we released packages 1.0.2.
ChangeLog:
**********
common
* added support for new automake
alsa-driver
* general
- fixed typo in configure for detecting RedHat kernels
- added resource allocation failure messages to all drivers
- fixes in PCI memory allocation routines
- fixed the build of 2.6 kernel with modversion
- fixed PCI DMA allocation for most PCI cards
- added SNDRV_PCM_STATE_DISCONNECTED state
- more complete sysfs support
- fixed 2.2 kernel support
- added the support of stack dump at xrun
- Change -EINVAL to -EALREADY in snd_pcm_unlink()
* added intel8x0 modem driver
* sb16 - fixed PnP problems
* au88x0 - added pci fixup code
* ens1371
- cleanups in s/pdif controls
- added rear/line-in switch
* via82xx
- fixed DXS volume value
- more quirks
* intel8x0
- fixed the 6 channel output on nforce
- added more quirks
- added the workaround for a hardware bug in intel 440MX B-stepping
* cmipci - improved s/pdif status bits initialization
* emu10k1
- renamed "Surround Digital" -> "Surround" to avoid ac97 name clashing
* emusynth
- added native API (hwdep) for soundfont handling
* USB audio driver
- add support for Edirol UM-1SX
- added quirk for Sound Blaster MP3+
* MPU401
- fix names for MPU-401 ports
* HDSP
- set the PCI latency timer to 255 for fixing some misbehavior
* OSS emulation
- fixed the oops in OSS mixer when the control elements are dynamically changed
- a next attempt to fix click at the end of stream
alsa-lib
* general
- added SNDRV_PCM_STATE_DISCONNECTED state
- fixed SHM memory leak fix in pcm routines
- fixed non-version build
- removed the function-in-function for qsort
- CMIPCI, ICE1712 - fixed the iec958 capture using asym plugin
* direct plugins
- close all file descriptors in server_job()
- improved compatibility with xine (fixes in poll() implemetation)
- added slowptr option which improves pointer accuracy
- dmix optimizations
alsa-utils
* improved amidi
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ 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.