* Re: After Uncompresseing Linux..., what's next
From: Prakash kanthi @ 2002-12-20 16:32 UTC (permalink / raw)
To: LinuxPPC
In-Reply-To: <20021220161436.81737.qmail@web41212.mail.yahoo.com>
I found the correct exception guys. It means
Privileged Instruction Exception.
--- Prakash kanthi <pkanthi@yahoo.com> wrote:
>
> Folks,
>
> I just wanted to provide more info on my env. I have
> PPC405 based board with no network support forcing
> me
> to use zImage.initrd.elf.
>
> Can you suggest more on my problem described below?
> I
> saw the memory values at 0x00000000 onwards after
> uncompressing linux and they have changed. But when
> the control jumps to 0x0, my board hangs. I see that
> ESR is showing a value of 0x80000000, meaning either
> illegal instruction or Machine Check.
>
> Can you tell what's going on? What happens next
> after
> uncompressing? I am thinking it executes
> start_kernel
> function which calls lock_kernel. Let me know if i
> am
> wrong.
>
> thanks,
> Prakash
>
>
>
>
> --- James Don <JDon@spacebridge.com> wrote:
> > I just went thru this myself ... ;-)
> >
> > 1.) Get a BDM/JTAG tool look halt the processor
> > after you see " Now booting
> > the kernel" and look for valid asm at 0x0 ... make
> > sure it mathes your
> > start.s file ...
> >
> > 2.) Veryfy you have your mem map from ppcboot
> > matching requirements for the
> > kernel i.e ram (physical=0x0, virtual=0xc0000000)
> > and immr (phys 0xff000000
> > virtual 0xff000000) ... I had my immr in ppc boot
> at
> > 0x02200000 this screwed
> > me for quite a while ... otherwise you have no
> > printk ... the memory map is
> > very important not to screw with some things
> depend
> > on it (unless your
> > careful) ...
> >
> > 3.) verify you SMC1 (uart) is getting proper
> > clocking config ... i.e
> > bus->brg1 and brg1 is 16 times baud rate ...
> > otherwise you have no printk
> >
> > 4.) and always always keep in mind your RAM refesh
> > could be wrong ...
> > everyone will tell you this even when it has
> nothing
> > to do with your problem
> > ... try not to ignore them if you are still stuck
> > ;-) But verifying step 1
> > should prove your ok ...
> >
> > Best of luck,
> > Jim
> >
> >
> > -----Original Message-----
> > From: Prakash kanthi [mailto:pkanthi@yahoo.com]
> > Sent: Wednesday, December 18, 2002 7:14 PM
> > To: LinuxPPC
> > Subject: After Uncompresseing Linux..., what's
> next
> >
> >
> > Hi there,
> >
> > I was trying to load linuxppc_2_4_devel onto my
> > board.
> > It goes through the board info read, UART init and
> > Uncompressing the linux kernel. But after that, i
> do
> > not see any messages and board hangs.
> >
> > Here is the UART output:
> > ------------------------------------
> > OS Booting...
> >
> > loaded at: 00400000 0060D1CC
> > board data at: 00000030 00000044
> > relocated to: 00405C24 00405C38
> > zimage at: 00406290 004A08FF
> > initrd at: 004A1000 006097CA
> > avail ram: 0060E000 007F8000
> >
> > Linux/PPC load: console=ttyS0,9600 console=tty1
> > ip=on
> > root=/dev/xsysace/disc0/pa
> > rt3 rw
> > Uncompressing Linux...done.
> > Now booting the kernel
> > -------------------------------------------
> >
> > After the last line, it hangs. I get a feeling
> that,
> > the uncompressing process is not writing in the
> > memory
> > starting from 0x00000000 and, after uncompressing,
> > it
> > is jumping into 0x00000000 and is not able to find
> > anything.
> >
> > My questions are,
> > 1. How can i make sure that, the uncompressing
> > process
> > is going to start writing the data from
> 0x00000000.
> >
> > 2. How big a space this uncompressing process
> needs?
> > And also how much overall memory is required for
> > running linux. I just have 8MB SDRAM.
> >
> > 3. What is the next step in the booting process?
> > Which
> > Device (eth, pci, ide, ???) Initialization?
> >
> > Your help is appreciated.
> >
> > thanks,
> > Prakash
> >
> >
>
>
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: shared pagetable benchmarking
From: Dave McCracken @ 2002-12-20 16:30 UTC (permalink / raw)
To: Andrew Morton, linux-mm
In-Reply-To: <3E02FACD.5B300794@digeo.com>
--On Friday, December 20, 2002 03:11:09 -0800 Andrew Morton
<akpm@digeo.com> wrote:
> The workload is application and removal of ~80 patches using
> my patch scripts. Tons and tons of forks from bash.
>
> 2.5 ends up being 13% slower than 2.4, after disabling highpte
> to make it fair. 3%-odd of this is HZ=1000. So say 10%.
>
> Pagetable sharing actually slowed this test down by several
> percent overall. Which is unfortunate, because the main
> thing which Linus likes about shared pagetables is that it
> "speeds up forks".
>
> Is there anything we can do to fix all of this up a bit?
Ok, let's consider just what shared page tables does for fork.
In fork without shared page tables, there is a fixed cost per mapped page
where the pte entry has to be copied from the parent's pte page to the
child's. This cost is higher for resident pages in 2.5 than 2.4 because of
rmap.
What shared page tables does isn't reduce that cost, it just defers it by
marking each pte page copy-on-write. The cost is incurred when either the
parent or the child first tries to write to a page in that pte page. The
savings comes when there are pte pages that never have to be unshared,
either because they map a shared region or they're not written to
(typically because the child quickly does an exec).
The worst case condition for shared page tables is when every pte page has
to be unshared. Unfortunately this is also a common case. Almost every
parent or child will touch three pages after fork: the current stack page,
libc's data page, and the application's data page. Each one of these is in
a separate pte page. Since each pte page maps 4M (2M for PAE), small
processes only have those three pte pages, and they're all unshared.
Unfortunately this includes most base utilities, in particular shells, so
shell scripts will not benefit from shared page tables.
There is a small penalty for deferring the pte page copy, as Andrew's tests
show. However, as soon as even one pte page is not copied, fork
performance improves dramatically. My tests show that fork/exit for a 4
pte page process is about 25% to 30% faster with shared page tables than
without, simply because of the single extra page that's not unshared. This
savings is multiplied for each additional pte page that remains shared.
I'll look for ways to optimize the unsharing to reduce the penalty, but I'm
not optimistic that we can eliminate it entirely.
Let's also not lose sight of what I consider the primary goal of shared
page tables, which is to greatly reduce the page table memory overhead of
massively shared large regions.
Dave McCracken
======================================================================
Dave McCracken IBM Linux Base Kernel Team 1-512-838-3059
dmccr@us.ibm.com T/L 678-3059
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply
* Re: Domain transition -- enabling user_r in eklogin
From: Jesse Pollard @ 2002-12-20 16:25 UTC (permalink / raw)
To: Russell Coker; +Cc: SELinux
In-Reply-To: <200212192333.12008.russell@coker.com.au>
On Thursday 19 December 2002 04:33 pm, Russell Coker wrote:
> On Thu, 19 Dec 2002 15:02, Jesse Pollard wrote:
> > > It's the same thing. If I can trick you into running some arbitary
> > > commands with your main role then I can get your ssh identity key and
> > > your gpg secret key. These crypto keys are often worth more than the
> > > hardware that they are stored on...
> >
> > Only if access is permitted to be over an unsecured channel.
> >
> > The differentation between a local user and a remote user has to be
> > provided.
>
> The "if I can trick you" part means that the distinction between local and
> remote logins is probably not relevant. Consider that you meet someone in
> Starbucks and say "there's this really cool program at www.foo.com" which
> they then download and run...
>
> Of course we could deny execute access to user_home_t but variations on the
> same theme can always be used while there are users who can be tricked and
> net access for easy back-channels.
>
> > Access to the secret key(s) probably should not be permitted from an
> > unsecured location/connection. This does require network labels to work.
>
> I guess you could have different roles, and have sshd only allow
> transitioning to a low security role which is prohibited from running ssh
> or gpg. I wonder whether a domain that only has full access to
> user_home_dir_t and user_home_t can misdirect the actions of ssh or gpg..
Only if ssh/gpg doesn't have the ability to distinguish between secure data
and insecure data. It would seem reasonable (for some level of reasonable)
that gpg should be able to sign less secure data using a normally inaccessable
secret key, IF it can recognize that changing/generating keys is not allowed
(or perhaps it should, provided the keys are also marked at the lower level -
multilevel filesystems are a bitch to debug)
> I don't think that network labels allow us to do anything productive in
> this regard as network operations are so abstracted. When a KDE ioslave
> can talk to a http proxy to get access to the outside network then making
> real use of network labels without seriously reducing functionality is
> almost impossible.
>
> For my aims a significant reduction in functionality is unacceptable.
I haven't analyzed how KDE is functioning yet, but full functionality would
still exist IF the application is communicating to a remote host/network that
can be trusted at the same level as the local system. As soon as it is
communicating with a less trusted media/medium then it really should start
being restricted.
If it is at a lower level, then yes, some functionality should be lost -
though that should not be significant, PROVIDED the X server and KDE know how
to compartmentalize the facilities communicating with that less trusted
service.
Note- things like multi-media applications should not really have that much
of a problem. The lowest level label used would be the data source. If the
other channels (local audio, video, and control interface) can provide multi
level capable controls, then a controled low level channel should be possible
for the audio/video output. The user would see no loss of functionality.
I realize that this is NOT a simple thing to do. It does require full
compartemented workstation support.
> > It does mean that the plugin for checking PGP signatures (at a minimum
> > the one for generating signatures) would have to be sufficiently separate
> > from the netscape process to be labeled separately. It could not use
> > loadable modules, for instance. It also means any scripts started should
> > not have access either.
>
> The problem is that if you can run GPG currently you can encrypt the secret
> key to yourself with a password (IE not encrypting to a public key) and
> then decrypt the result to get the key. A future version of GPG will
> address this. I don't know how PGP performs in this regard.
Yup. That is one of the things the application must be able to evaluate. The
output media/medium is the determining factor here. To do this requires
reading data with a high level label by a trusted process which must NOT
write that data to a media/medum with a low level label. That trusted process
SHOULD be able to read low labeled data, munch it using high labled data,
and write it to a low labeled media/medum since this is WHY it is a trusted
process.
Granted some attacks do become possible. The low level data might be null,
permitting a potential brute force attack with a known text. There are likely
other forms of attack too. Most of these can be remedied by adding in a random
string to prevent null text. It would become more usable and more transparent
to the user that way.
> > This is not a 100% solution - If netscape is used to download an
> > application, then the user proceeds to configure/compile/run then all
> > bets are off since the users actions are overriding the labels. It
> > should/could prevent a trojan from passing the files out though - it
> > would not be authorized access to the secret key(s) or the Kerberos
> > ticket cache. Only trusted utilities would have that capability.
>
> However if the ticket can't be used on other machines then the concern is
> not that it will be passed out, but that a process holding the ticked will
> be controlled by a program that is a proxy running on behalf of a program
> outside.
correct. That requires the program that is trusted to be able to evaluate the
security environment before taking action.
> One of my friends wrote a nifty set of CGI scripts to run a terminal
> session through a web page using standard web forms functionality. It
> wouldn't be THAT much more difficult to do it the other way around and have
> machine running bash be the HTTP client and the HTTP server have the client
> side of the shell session.
Yup - have seen that one too. The usual remedy for this is that the trusted
application evaluates it's security environment. The pty is assigned the
level of the CGI. If the CGI is less trusted by the server it should be run
at a low security level. That terminal session could then attempt to run a
trusted process. however, if that trusted process attempts to write/obtain the
secret key, then it would/should refuse since it cannot operate higher than
it's environment, as defined by the terminal session.
Personally, I dislike the idea of privileged applications. For a secure
environment, I would prever all secret keys to be maintained by a security
server process, and all queries/updates for access to this data to be carried
out by that security server. This would turn at least half of GPG/Kerberos
functions over to the security server (which should pass the actions on the
keys to sub processes. That includes encryption/decryption services, though
the security server may just pass a socket connection back to the requesting
application to allow that application to push data into the encryption engine
and either recieve the results, or the output could already be connected to
another socket for outgoing data.
Complicated perhaps, but no trusted application need exist other than the
security server. And the users would have no need to access the secret keys
directly.
Currently, the kerberos server side does exactly this - the untrusted remote
must authenticate to the server, once trust is established, the server
interposes an encryption server between the terminal session and the remote
encryption client. If this were split up as above, then the kerberized telnet
operation becomes equivalent to the old telnet process except:
1. the telnet client requests a connection to the remote server by passing the
request to the security server.
2. the security server takes the security level of the request from the
process requesting it
3. the outgoing connection is established by the security server and labeled
at the requesting level. The remote security server can then request
authentication by whatever means accepted to both
4. Assuming acceptance, the security server puts an encryption service (if
required) between the client and the outgoing socket.
5. The remote security server would put another encryption service between the
incoming socket and the application server, running at the same level as
the incoming socket label.
It would then be up to the application server whether to create a terminal
session or other processing server. The security server on both systems would
be controlling access to any secret keys needed.
Connection "acceptance" would be negotiated via (in this case) a kerberos
authenction, any ticket forwarding handling, required encryption services,
and label matching - would all be handled by the security server. It would
even permit different algorithms to be selected. Might use AES to one system,
3DES to another, or RSA/Blowfish/... whatever was agreed upon by the two
systems.
--
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* RE: [PATCH][2.4] generic cluster APIC support for systems with m ore than 8 CPUs
From: Martin J. Bligh @ 2002-12-20 16:30 UTC (permalink / raw)
To: Van Maren, Kevin, 'William Lee Irwin III',
Christoph Hellwig, James Cleverdon, Pallipadi, Venkatesh,
Linux Kernel, John Stultz, Nakajima, Jun, Mallick, Asit K,
Saxena, Sunil
Cc: Protasevich, Natalie
In-Reply-To: <3FAD1088D4556046AEC48D80B47B478C0101F55D@usslc-exch-4.slc.unisys.com>
> Natalie is the engineer who added support for the ES7000 to Linux.
> Fortunately she is in the cube next to me.
>
> She has sent the patches to SuSe/United Linux, and is in the final process
> of testing them on 2.5.5x before submitting them to LKML for comment.
Are they under subarch or somehow abstracted this time, or are there
going to be 10,000 ifdef's again? If the latter, I can predict what
the first set of review comments you get are going to be ;-)
M.
^ permalink raw reply
* E1/T1 on mpc8260.
From: Omanakuttan @ 2002-12-20 16:21 UTC (permalink / raw)
To: linuxppc-embedded
Greetings,
We are developing a bridge which will convert 7 E1/T1 channels to
100Mbps ethernet using mpc8260 and Exar XRT84L38 Octal framer.
According the design, TDMs will be fed data from octal T1/E1 framer. I
will have to program the MCC to accept data from the TDMs and give it to
a pppd daemon.
If the TDMs are fed data from the framer (i.e. E1/T1's stripped of
signaling and channeling information), how many channels do I have to
program in the MCC?
Do I have to program one channel for each E1/T1 lines or 30 channels for
each E1 and 24 channels for each T1s? Or any of the approach is OK
provided I do not want the 64kbps granularity and ready to accept it as
a big stram of bytes (64 x 30 kbps)? if I do so, can I demultiplex it
using some other device?
if one E1 is accepted as one channel in MCC, then why is it stated that
it takes 128 channels of 64k each? (MPC8260UM.pdf,
The motorola manual uses the term `channel` both for E1 lines and the
thirty (or 32) 'channels' inside it. I am confused.
Any help is appreciated.
Thanks and regards,
Om.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* After Uncompresseing Linux..., what's next
From: Prakash kanthi @ 2002-12-20 16:14 UTC (permalink / raw)
To: LinuxPPC
In-Reply-To: <DB0585C9F6F9D411BE8F00D0B7896A4CC05F66@SNCMAIL>
Folks,
I just wanted to provide more info on my env. I have
PPC405 based board with no network support forcing me
to use zImage.initrd.elf.
Can you suggest more on my problem described below? I
saw the memory values at 0x00000000 onwards after
uncompressing linux and they have changed. But when
the control jumps to 0x0, my board hangs. I see that
ESR is showing a value of 0x80000000, meaning either
illegal instruction or Machine Check.
Can you tell what's going on? What happens next after
uncompressing? I am thinking it executes start_kernel
function which calls lock_kernel. Let me know if i am
wrong.
thanks,
Prakash
--- James Don <JDon@spacebridge.com> wrote:
> I just went thru this myself ... ;-)
>
> 1.) Get a BDM/JTAG tool look halt the processor
> after you see " Now booting
> the kernel" and look for valid asm at 0x0 ... make
> sure it mathes your
> start.s file ...
>
> 2.) Veryfy you have your mem map from ppcboot
> matching requirements for the
> kernel i.e ram (physical=0x0, virtual=0xc0000000)
> and immr (phys 0xff000000
> virtual 0xff000000) ... I had my immr in ppc boot at
> 0x02200000 this screwed
> me for quite a while ... otherwise you have no
> printk ... the memory map is
> very important not to screw with some things depend
> on it (unless your
> careful) ...
>
> 3.) verify you SMC1 (uart) is getting proper
> clocking config ... i.e
> bus->brg1 and brg1 is 16 times baud rate ...
> otherwise you have no printk
>
> 4.) and always always keep in mind your RAM refesh
> could be wrong ...
> everyone will tell you this even when it has nothing
> to do with your problem
> ... try not to ignore them if you are still stuck
> ;-) But verifying step 1
> should prove your ok ...
>
> Best of luck,
> Jim
>
>
> -----Original Message-----
> From: Prakash kanthi [mailto:pkanthi@yahoo.com]
> Sent: Wednesday, December 18, 2002 7:14 PM
> To: LinuxPPC
> Subject: After Uncompresseing Linux..., what's next
>
>
> Hi there,
>
> I was trying to load linuxppc_2_4_devel onto my
> board.
> It goes through the board info read, UART init and
> Uncompressing the linux kernel. But after that, i do
> not see any messages and board hangs.
>
> Here is the UART output:
> ------------------------------------
> OS Booting...
>
> loaded at: 00400000 0060D1CC
> board data at: 00000030 00000044
> relocated to: 00405C24 00405C38
> zimage at: 00406290 004A08FF
> initrd at: 004A1000 006097CA
> avail ram: 0060E000 007F8000
>
> Linux/PPC load: console=ttyS0,9600 console=tty1
> ip=on
> root=/dev/xsysace/disc0/pa
> rt3 rw
> Uncompressing Linux...done.
> Now booting the kernel
> -------------------------------------------
>
> After the last line, it hangs. I get a feeling that,
> the uncompressing process is not writing in the
> memory
> starting from 0x00000000 and, after uncompressing,
> it
> is jumping into 0x00000000 and is not able to find
> anything.
>
> My questions are,
> 1. How can i make sure that, the uncompressing
> process
> is going to start writing the data from 0x00000000.
>
> 2. How big a space this uncompressing process needs?
> And also how much overall memory is required for
> running linux. I just have 8MB SDRAM.
>
> 3. What is the next step in the booting process?
> Which
> Device (eth, pci, ide, ???) Initialization?
>
> Your help is appreciated.
>
> thanks,
> Prakash
>
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: reiserfsck --rebuild-tree on a big filesystem
From: Zygo Blaxell @ 2002-12-20 16:12 UTC (permalink / raw)
To: reiserfs-list
In-Reply-To: <att918$u36$1@genki.hungrycats.org>
In article <att918$u36$1@genki.hungrycats.org>,
Zygo Blaxell <eazgwmir@umail.furryterror.org> wrote:
>I guess I'll find out in 7 hours what the semantic pass will be like.
>Fortunately I don't need to use this particular filesystem until 2003,
>so there is time to run little experiments like this...
reiserfsck has gotten to pass 3 and is now doing a search of the
filesystem tree file-by-file. It appears to be progressing without
any major CPU or memory problems.
Traversing the filesystem tree on this machine (e.g. with 'find')
normally takes 3 days, so I guess we'll know if it works just in time
for Christmas. ;-)
Is it normal to see hundreds of
vpf-10680: The file [5029518 5034490] has the wrong block count in the StatData (16) - corrected to (8)
messages?
--
Opinions expressed are my own, I don't speak for my employer, and all that.
Encrypted email preferred. Go ahead, you know you want to. ;-)
OpenPGP at work: 3528 A66A A62D 7ACE 7258 E561 E665 AA6F 263D 2C3D
^ permalink raw reply
* Re: alsasound init script (Re: possible problems with rc6 aplay )
From: Clemens Ladisch @ 2002-12-20 16:10 UTC (permalink / raw)
To: Takashi Iwai
Cc: Mark Knecht, Fernando Pablo Lopez-Lezcano, Paul Davis, Alsa-Devel
In-Reply-To: <s5hadj0vi85.wl@alsa2.suse.de>
Takashi Iwai wrote:
> Mark Knecht wrote:
> > I was wondering what would happen in this process if someone had two r
> > three identical USB devices, like the MidiMan 2X2? OR also two identical
> > cards like the RME HDSP 9652?
>
> when a module is loaded and two or more identical (or supported)
> devices are connected, the module will initialize the all such devices
> at once.
>
> for multiple devices, you can specify the options separated by commas,
>
> > It is important that the system recognize the same hardware as the same
> > sound device every time the machine booted, and whether the machine is
> > warm or cold booted.
>
> in the case of usb, it's not 100% sure, because it's anyway
> hotpluggable. but usually the order of probing is identical, so it's
> ok.
It is possible to force USB devices to a specific index with the vid/pid
parameters for the vendor/product id, even when hotplugging.
However, this won't work when you hotplug two identical devices (with the
same product id).
Clemens
-------------------------------------------------------
This SF.NET email is sponsored by: The Best Geek Holiday Gifts!
Time is running out! Thinkgeek.com has the coolest gifts for
your favorite geek. Let your fingers do the typing. Visit Now.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* Re: Sony Vaio Battery Info
From: Stephen White @ 2002-12-20 16:09 UTC (permalink / raw)
To: Markus Gaugusch; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <Pine.LNX.4.50.0212192106570.950-100000-KjnUIgV0B0bsKMwAuzqOxrNldLUNz+W/@public.gmane.org>
---- Original Message ----
> From Markus Gaugusch <markus-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org>
> Date: Thursday, 19 Dec 2002, 20:13
>
> I don't really know how to do this (finding the ec code won't be so hard,
> but I don't think that 'normal' libc time functions will work in kernel).
> Any volunteers? ;)
You shouldn't need to use the time functions .. just print out the
kernel's 'jiffy' count. It's only 100Hz but since we're looking for
0.6s that shouldn't matter.
If you need debug timings more precisely then on x86:
#define _int64 long long // The kernel may have something like this already .. I can't remember
#define prectime() ({ _int64 u; asm("rdtsc": "=A" (u)); u; })
will give you a way of accessing the time stamp counter which on Pentium
class chips will count CPU cycles .. which gives somewhat more precise
profiling information.
This is something I keep meaning to look at, but I seem to be missing a
large number of 'tuits' (especially the round variety).
--
Stephen White <stephen-acpi-devel-4QvXXjU8Dv4@public.gmane.org>
-------------------------------------------------------
This SF.NET email is sponsored by: The Best Geek Holiday Gifts!
Time is running out! Thinkgeek.com has the coolest gifts for
your favorite geek. Let your fingers do the typing. Visit Now.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Martin J. Bligh @ 2002-12-20 16:08 UTC (permalink / raw)
To: John Bradford; +Cc: linux-kernel
In-Reply-To: <200212200948.gBK9mrXh000326@darkstar.example.net>
> Not sure what you mean. I do intend to start coding a new bug
> database system today, and I'll announce it on the list when it's
> ready. If nobody likes it, I wasted my time.
That's basically what I meant ... try coding it and see. My wierd
Anglicisms in forms of speech ...
>> Have you actually looked at the maintainers file?
>
> Yes.
>
>> It's a twisted mess of outdated information,
>
> Then it should be updated, that is nothing to do with Bugzilla.
Right. But I wasn't interested in doing that. And code maintainers
won't necessarily want to be bug database maintainers (though I did
get a suprising number of people to sign up).
>> The category list in Bugzilla was an attempt to bring some sanity to
>> the structure,
>
> By adding an extra layer of abstraction. I don't agree that that
> helps.
Well, I guess we differ on that then.
>> though I won't claim it's perfect. We really need a 3-level tree,
>> but that's a fair amount of work to code.
>
> I disagree, (that we need a 3-level tree).
We don't *need* one, it'd be nice though.
M.
^ permalink raw reply
* Re: PTRACE_GET_THREAD_AREA
From: Daniel Jacobowitz @ 2002-12-20 16:08 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: Roland McGrath, linux-kernel, Ingo Molnar
In-Reply-To: <20021220105513.J27455@devserv.devel.redhat.com>
On Fri, Dec 20, 2002 at 10:55:16AM -0500, Jakub Jelinek wrote:
> On Fri, Dec 20, 2002 at 10:48:29AM -0500, Daniel Jacobowitz wrote:
> > Eventually most or all targets will have thread-specific data
> > implemented; I don't want to have to redo this for each one.
>
> Well, but on most arches you don't need any kernel support for TLS.
> On sparc32/sparc64/IA-64/s390/s390x and others you simply have one
> general register reserved for it by the ABI, on Alpha you use a PAL
> call.
> set_thread_area/get_thread_area is IA-32/x86-64 specific.
Oh, right, I guess we won't need anything if it's just in a register :)
Architecture-specific it is, then. For Alpha (and probably MIPS) we
can add a ptrace equivalent of the trap to fetch the pointer. Patch
looks fine to me.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply
* Re: dosemu-1.1.4 compile error.
From: Bart Oldeman @ 2002-12-20 15:52 UTC (permalink / raw)
To: Michael; +Cc: linux-msdos
In-Reply-To: <200212201143.MAA16450@mail47.fg.online.no>
On Fri, 20 Dec 2002, Michael wrote:
> make[2]: Entering directory `/home/michael/stuff/progs/install/dosemu/dosemu-1.1.4/src/base/init'
> bison -y -v -do parser.c parser.y
> parser.y:1338.3-61: type clash (`' `i_value') on default action
> make[2]: *** [parser.c] Error 1
> make[2]: Leaving directory `/home/michael/stuff/progs/install/dosemu/dosemu-1.1.4/src/base/init'
> make[1]: *** [base/init] Error 2
> make[1]: Leaving directory `/home/michael/stuff/progs/install/dosemu/dosemu-1.1.4/src'
> make: *** [default] Error 2
>
> bison (GNU Bison) 1.50
> gcc (GCC) 3.2.1
I see nothing suspicious there. Just tried with Bison 1.75 and it compiles
just fine for me, so consider upgrading (or downgrading, 1.28 works
fine too) your Bison.
Bart
^ permalink raw reply
* Re: PTRACE_GET_THREAD_AREA
From: Jakub Jelinek @ 2002-12-20 15:55 UTC (permalink / raw)
To: Roland McGrath, linux-kernel, Ingo Molnar
In-Reply-To: <20021220154829.GB17007@nevyn.them.org>
On Fri, Dec 20, 2002 at 10:48:29AM -0500, Daniel Jacobowitz wrote:
> Eventually most or all targets will have thread-specific data
> implemented; I don't want to have to redo this for each one.
Well, but on most arches you don't need any kernel support for TLS.
On sparc32/sparc64/IA-64/s390/s390x and others you simply have one
general register reserved for it by the ABI, on Alpha you use a PAL
call.
set_thread_area/get_thread_area is IA-32/x86-64 specific.
Jakub
^ permalink raw reply
* Re: Linux 2.4.21-pre2
From: Ben Collins @ 2002-12-20 15:50 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Marcelo Tosatti, lkml, linux1394-devel
In-Reply-To: <20021220144808.GF27658@fs.tum.de>
> -o vmlinux
> ld: cannot open drivers/ieee1394/ieee1394drv.o: No such file or directory
> make: *** [vmlinux] Error 1
I'm not even sure how the hell that change to Makefile got in there.
Probably something we merged for kernel 2.5 before we branched.
Thanks, I'll get it fixed up.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
^ permalink raw reply
* RE: [PATCH][2.4] generic cluster APIC support for systems with m ore than 8 CPUs
From: Van Maren, Kevin @ 2002-12-20 15:46 UTC (permalink / raw)
To: 'William Lee Irwin III', Christoph Hellwig,
James Cleverdon, Pallipadi, Venkatesh, Linux Kernel, Martin Bligh,
John Stultz, Nakajima, Jun, Mallick, Asit K, Saxena, Sunil,
Van Maren, Kevin
Cc: Protasevich, Natalie
> On Thu, Dec 19, 2002 at 06:04:55PM -0800, James Cleverdon wrote:
> >>> A generic patch should also support Unisys' new box, the ES7000 or
> >>> some such.
>
> On Fri, Dec 20, 2002 at 08:00:50AM +0000, Christoph Hellwig wrote:
> >> That box needs more changes than just the apic setup. Unfortunately
> >> unisys thinks they shouldn't send their patches to lkml, but when you
see
> >> them e.g. in the suse tree it's a bit understandable that they don't
want
> >> anyone to really see their mess :)
No need to sugar-coat anything :-)
Natalie is the engineer who added support for the ES7000 to Linux.
Fortunately she is in the cube next to me.
She has sent the patches to SuSe/United Linux, and is in the final process
of testing them on 2.5.5x before submitting them to LKML for comment.
> >> And btw, the box isn't that new, but three years ago or so when they
first
> >> showed it on cebit they even refused to talk about linux due to their
> >> restrictive agreements with Microsoft..
>
> On Fri, Dec 20, 2002 at 03:24:01AM -0800, William Lee Irwin III wrote:
> > Kevin, you're the only lkml-posting contact point I know of within
Unisys.
> > Is there any chance you could flag down some of the ia32 crew there for
> > some commentary on this stuff? (or do so yourself if you're in it)
I mostly work on our 16-32p IA64 machines. Natalie or someone else will
have to comment on the clustered-apic code.
I do know that a lot of the code for the ES7000 is optional, and only
required to support value-added management functionality, which is
especially useful if you are running more than one OS instance on the
machine (it supports 8 fully-independent partitions).
Also, as a clarification, our 32-processor systems are NOT NUMA: there
is a full non-blocking crossbar to memory. So clustered APIC support
should not be dependant on NUMA.
Kevin
^ permalink raw reply
* Re: PTRACE_GET_THREAD_AREA
From: Daniel Jacobowitz @ 2002-12-20 15:48 UTC (permalink / raw)
To: Roland McGrath; +Cc: linux-kernel, Ingo Molnar
In-Reply-To: <200212200832.gBK8Wfg29816@magilla.sf.frob.com>
On Fri, Dec 20, 2002 at 12:32:41AM -0800, Roland McGrath wrote:
> This patch vs 2.5.51 (should apply fine to 2.5.52) adds two new ptrace
> requests for i386, PTRACE_GET_THREAD_AREA and PTRACE_SET_THREAD_AREA.
> These let another process using ptrace do the equivalent of performing
> get_thread_area and set_thread_area system calls for another thread.
>
> We are working on gdb support for the new threading code in the kernel
> using the new NPTL library, and use PTRACE_GET_THREAD_AREA for that.
> This patch has been working fine for that.
>
> I added PTRACE_SET_THREAD_AREA just for completeness, so that you can
> change all the state via ptrace that you can read via ptrace as has
> previously been the case. It doesn't have an equivalent of set_thread_area
> with .entry_number = -1, but is otherwise the same.
>
> Both requests use the ptrace `addr' argument for the entry number rather
> than the entry_number field in the struct. The `data' parameter gives the
> address of a struct user_desc as used by the set/get_thread_area syscalls.
>
> The code is quite simple, and doesn't need any special synchronization
> because in the ptrace context the thread must be stopped already.
>
> I chose the new request numbers arbitrarily from ones not used on i386.
> I have no opinion on what values should be used.
>
> People I talked to preferred adding this interface over putting an array of
> struct user_desc in struct user as accessed by PTRACE_PEEKUSR/POKEUSR
> (which would be a bit unnatural since those calls access one word at a time).
In general, I like this. However, I have to ask one question: how much
of the i386-centrism of this patch is actually necessary? What
information does GDB _use_ from this, and is there some way we can
expose it that will be useful in other places?
Eventually most or all targets will have thread-specific data
implemented; I don't want to have to redo this for each one.
Your choice of numbers is fine if this remains i386-centric; if we
expect there to be a common interface then it should go in
<linux/ptrace.h> and the 0x4200 range instead.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply
* Re: [PATCH]: make highmem only things enclosed in the right #ifdef
From: Maciej W. Rozycki @ 2002-12-20 15:37 UTC (permalink / raw)
To: Juan Quintela; +Cc: linux mips mailing list, Ralf Baechle
In-Reply-To: <m2y96lf03f.fsf@demo.mitica>
On 20 Dec 2002, Juan Quintela wrote:
> Do you preffer this way?
It's actually alike to me. I was ambiguous -- sorry for that. But in
the context of spacing changes, I assumed it will be obvious I refer to
the double empty line.
Anyway, the pgd_base variable seems superfluous here. This patch is
fine. Thanks for working on it.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Eli Carter @ 2002-12-20 15:43 UTC (permalink / raw)
To: Dave Jones; +Cc: Hanna Linder, Pete Zaitcev, linux-kernel
In-Reply-To: <20021220103027.GF24782@suse.de>
Dave Jones wrote:
> On Thu, Dec 19, 2002 at 04:19:03PM -0800, Hanna Linder wrote:
>
> > Im trying to help make it easier for such people to get a list
> > of bugs to start working on. If it looks like everything already
> > has an owner it looks like there is nothing to do.
>
> Just because a bug is 'owned' does not stop someone else working on it.
> That would be silly. All the owner field says is, "if someone is
> interested in this bug, and they happen to fix before $owner does,
> $owner would like to know about it." This way $owner can reject bad
> fixes, or get further clues as to whats actually causing the problem.
>
> > Hanna (obviously not a bugzilla user before)
>
> Obviously 8-)
I'm new to bugzilla too... I noticed there is a link "Give me a clue
about how to use this form." I think that needs to be at the top of the
query form, with a nice '?' graphic beside it. I suspect that would
help a lot.
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
^ permalink raw reply
* Re: PTRACE_GET_THREAD_AREA
From: Daniel Jacobowitz @ 2002-12-20 15:44 UTC (permalink / raw)
To: Christoph Hellwig, Roland McGrath, linux-kernel, Ingo Molnar
In-Reply-To: <20021220102431.A26923@infradead.org>
On Fri, Dec 20, 2002 at 10:24:31AM +0000, Christoph Hellwig wrote:
> On Fri, Dec 20, 2002 at 12:32:41AM -0800, Roland McGrath wrote:
> > This patch vs 2.5.51 (should apply fine to 2.5.52) adds two new ptrace
> > requests for i386, PTRACE_GET_THREAD_AREA and PTRACE_SET_THREAD_AREA.
> > These let another process using ptrace do the equivalent of performing
> > get_thread_area and set_thread_area system calls for another thread.
>
> I don't think ptrace is the right interface for this. Just changed
> the get_thread_area/set_thread_area to take a new first pid_t argument.
>
> Of course you might have to check privilegues if the first argument is
> non-null (i.e. not yourself).
I have to disagree. These are things which you should never do to
another process unless you're ptracing them; get_thread_area with a PID
is not generally useful.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply
* Re: Valgrind meets UML
From: John Reiser @ 2002-12-20 15:26 UTC (permalink / raw)
To: Jeff Dike; +Cc: linux-kernel, Jeremy Fitzhardinge, Julian Seward
In-Reply-To: <200212200241.VAA04202@ccure.karaya.com>
Jeff Dike wrote:
> I would also appreciate suggestions on what sort of memory access state table
> to implement, and where best to put the declarations. What I'm not clear
> on is what sort of access a buffer should have when it's in the care of
> the allocator (i.e. it's free). If the allocator sticks information
> temporarily in the buffer, then that needs to be stated.
Probably there will be some benefits, at least for a while, if valgrind for UML
"knows" the kernel allocators like valgrind for applications "knows" malloc+free.
Implementors of allocators can have bugs in the valgrind declarations they add.
An "independent" check based on documented externally-visible behavior can help.
Nested allocators (inner allocator grabs a large region, outer allocator performs
sub-allocations of small pieces from the large region) can be troublesome.
Implementing a four-state status {-, W, RW, RO} might be much more work,
because some accounting schemes are oriented naturally towards only three states
{-, W, RW}. Also, there are contenders for two additional states: watchpoints
for READ and WRITE, such as "any read of a back-pointer of this doubly-linked
list", etc.
--
John Reiser, jreiser@BitWagon.com
^ permalink raw reply
* Re: [parisc-linux] 2.4.21-pre2 : sysctl.h pb
From: Randolph Chung @ 2002-12-20 15:20 UTC (permalink / raw)
To: jsoe0708; +Cc: parisc-linux
In-Reply-To: <3E0085D000000500@ocpmta5.freegates.net>
> Merging 2.4.21-pre2 with parisc tree, I notice the following the following
> pb:
just bump the hppa numbers
> KERN_HPPA_PWRSW=55, /* int: hppa soft-power enable */
> KERN_HPPA_UNALIGNED=56, /* int: hppa unaligned-trap enable */
make these 57, 58 or so
it seems a bit odd to me that the sysctl number space is not
partitioned, but...
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
^ permalink raw reply
* Re: alsasound init script (Re: possible problems with rc6 aplay )
From: Takashi Iwai @ 2002-12-20 15:10 UTC (permalink / raw)
To: Mark Knecht; +Cc: Fernando Pablo Lopez-Lezcano, Paul Davis, Alsa-Devel
In-Reply-To: <1040217097.1370.7.camel@Godzilla>
At 18 Dec 2002 05:11:36 -0800,
Mark Knecht wrote:
>
> On Wed, 2002-12-18 at 03:17, Takashi Iwai wrote:
> > At Wed, 18 Dec 2002 11:46:45 +0100,
> > I wrote:
> > >
> > > > It would be better to make the alsasound script more robust (and
> > > > independent of the startup order) and able to deal with partially loaded
> > > > modules, so instead of just checking for the /proc/asound directory it
> > > > would actually see what modules are already loaded and only load those
> > > > that are not. It does not look too easy, it seems that /proc/asound does
> > > > not provide a list of loaded modules (rather a list of cards that are
> > > > not associated with module names).
> > >
> > > agreed. a scenario i can imagine now is that the script just takes a
> > > look at /proc/asound/cards and checks the numbers at the first column.
> > > this should correspond to the card indices which have been already
> > > loaded. then the script will try to load the modules snd-card-X but
> > > skip the numbers listed in the above...
> > > i'll try to rewrite as this way.
> >
> > after reconsideration: it would be much simpler to create a new proc
> > file which shows the modules already loaded.
> >
> I was wondering what would happen in this process if someone had two r
> three identical USB devices, like the MidiMan 2X2? OR also two identical
> cards like the RME HDSP 9652?
when a module is loaded and two or more identical (or supported)
devices are connected, the module will initialize the all such devices
at once.
for multiple devices, you can specify the options separated by commas,
options snd-hdsp index=1,2,3 id="hdsp1","hdsp2","hdsp3"
if there is no index option given for a device, as mentioned before,
an empty slot is probed from the index 0. thus, if you don't set any
index options for all modules, that's fine, except for that the order
of devices is not guaranteed. (cards_limit option must be enough
large, or you need to apply my patch.)
for keeping the order of devices, giving the index option for each
device would be better.
> It is important that the system recognize the same hardware as the same
> sound device every time the machine booted, and whether the machine is
> warm or cold booted.
in the case of usb, it's not 100% sure, because it's anyway
hotpluggable. but usually the order of probing is identical, so it's
ok.
Takashi
-------------------------------------------------------
This SF.NET email is sponsored by: The Best Geek Holiday Gifts!
Time is running out! Thinkgeek.com has the coolest gifts for
your favorite geek. Let your fingers do the typing. Visit Now.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* Re: use bdi on board with ppcbug
From: Wolfgang Denk @ 2002-12-20 15:10 UTC (permalink / raw)
To: 于婧; +Cc: linuxppc-embedded@lists.linuxppc.org
In-Reply-To: <200212200829.CAA05221@lists.linuxppc.org>
In message <200212200829.CAA05221@lists.linuxppc.org> you wrote:
>
> I want to debug the kernel on the motorola lopec p011 board with bdi tools.
> And the first thing I must solve is to let the ppcbug "go" under the bdi control.But I don't know where the entry of ppcbug is,so I can't "go" the ppcbug.Has anybody know that?Or,the ppcbug can not be run under this circumstances?
Just type "reset", followed by "go".
Like any other boot loader, ppcbug will strat right from the reset
vector.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
Eschew obfuscation.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Walnut configuration (old problem)
From: Wolfgang Denk @ 2002-12-20 15:09 UTC (permalink / raw)
To: llandre; +Cc: linuxppc-embedded
In-Reply-To: <5.1.1.6.0.20021220132028.02337438@dns.struinfo.it>
In message <5.1.1.6.0.20021220132028.02337438@dns.struinfo.it> you wrote:
>
> I've just start working with the Walnut board. I downloaded:
> 1) linuxppc_2_4 with rsync
> 2) linuxppc_2_4_devel with rsync
> 3) linuxppc_2_4_devel with bk
>
> but in all cases I encountered the same problem described here
> http://lists.linuxppc.org/linuxppc-embedded/200207/msg00005.html.
Did you remember to set (in the top level Makefile) the definition of
ARCH to "ppc"?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
You are only young once, but you can stay immature indefinitely.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [PATCH 2.5.52] NUMA scheduler (1/2)
From: Christoph Hellwig @ 2002-12-20 15:17 UTC (permalink / raw)
To: Erich Focht
Cc: Martin J. Bligh, Michael Hohnbaum, Robert Love, Ingo Molnar,
Stephen Hemminger, linux-kernel
In-Reply-To: <200212181721.39434.efocht@ess.nec.de>
diff -urN a/arch/i386/kernel/smpboot.c b/arch/i386/kernel/smpboot.c
--- a/arch/i386/kernel/smpboot.c 2002-12-16 03:07:56.000000000 +0100
+++ b/arch/i386/kernel/smpboot.c 2002-12-18 16:53:12.000000000 +0100
@@ -1202,6 +1202,9 @@
void __init smp_cpus_done(unsigned int max_cpus)
{
zap_low_mappings();
+#ifdef CONFIG_NUMA
+ build_node_data();
+#endif
I think it would be much nicer if you had a proper stub for !CONFIG_NUMA..
@@ -20,6 +20,7 @@
#include <asm/mmu.h>
#include <linux/smp.h>
+#include <asm/topology.h>
Another header in sched.h?? And it doesn't look like it's used at all.
#include <linux/sem.h>
#include <linux/signal.h>
#include <linux/securebits.h>
@@ -446,6 +447,9 @@
# define set_cpus_allowed(p, new_mask) do { } while (0)
#endif
+#ifdef CONFIG_NUMA
+extern void build_node_data(void);
+#endif
The ifdef is superflous.
diff -urN a/kernel/sched.c b/kernel/sched.c
--- a/kernel/sched.c 2002-12-16 03:08:14.000000000 +0100
+++ b/kernel/sched.c 2002-12-18 16:53:13.000000000 +0100
@@ -158,6 +158,10 @@
struct list_head migration_queue;
atomic_t nr_iowait;
+
+ unsigned long wait_time;
+ int wait_node;
+
Here OTOH a #if CONFIG_MUA could help to avoid a little bit of bloat.
} ____cacheline_aligned;
+#define cpu_to_node(cpu) __cpu_to_node(cpu)
I wonder why we don't have a proper cpu_to_node() yet, but as long
as it doesn't exist please use __cpu_to_node() directly.
+#define LOADSCALE 128
Any explanation?
+#ifdef CONFIG_NUMA
sched.c uses #if CONFIG_FOO, not #ifdef CONFIG_FOO, it would be cool
if you could follow the style of existing source files.
+/* Number of CPUs per node: sane values until all CPUs are up */
+int _node_nr_cpus[MAX_NUMNODES] = { [0 ... MAX_NUMNODES-1] = NR_CPUS };
+int node_ptr[MAX_NUMNODES+1]; /* first cpu of node (logical cpus are sorted!)*/
+#define node_ncpus(node) _node_nr_cpus[node]
Parametrized macros and variables aren't in the ßame namespace, what about
just node_nr_cpus for the macro, too. And should these be static?
+
+#define NODE_DELAY_IDLE (1*HZ/1000)
+#define NODE_DELAY_BUSY (20*HZ/1000)
Comments, please..
+/* the following macro implies that logical CPUs are sorted by node number */
+#define loop_over_node(cpu,node) \
+ for(cpu=node_ptr[node]; cpu<node_ptr[node+1]; cpu++)
Move to asm/topology.h?
+ ptr=0;
+ for (n=0; n<numnodes; n++) {
You need to add lots of space to match Documentation/odingStyle.. :)
+ for (cpu = 0; cpu < NR_CPUS; cpu++) {
+ if (!cpu_online(cpu)) continue;
And linebreaks..
Btw, what about a for_each_cpu that has the cpu_online check in topology.h?
+ /* Wait longer before stealing if own node's load is average. */
+ if (NODES_BALANCED(avg_load,nd[this_node].average_load))
Shouldn't NODES_BALANCED shout less and be an inline called nodes_balanced?
+ this_rq->wait_node = busiest_node;
+ this_rq->wait_time = jiffies;
+ goto out;
+ } else
+ /* old most loaded node: check if waited enough */
+ if (jiffies - this_rq->wait_time < steal_delay)
+ goto out;
That indentation looks really strange, why not just
/* old most loaded node: check if waited enough */
} else if (jiffies - this_rq->wait_time < steal_delay)
goto out;
+
+ if ((!CPUS_BALANCED(nd[busiest_node].busiest_cpu_load,*nr_running))) {
Dito, the name shouts a bit too much
+#endif
#endif /* CONFIG_NUMA */
-#define BUSY_REBALANCE_TICK (HZ/4 ?: 1)
+#define BUSY_REBALANCE_TICK (HZ/5 ?: 1)
And explanation why you changed that constant?
p = req->task;
- cpu_dest = __ffs(p->cpus_allowed);
+ cpu_dest = __ffs(p->cpus_allowed & cpu_online_map);
+
This looks like a bugfix valid without the rest of the patch.
^ 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.