[EMAIL PROTECTED] said:
> for crying out loud, even windows tells the users they need to
> shutdown first and gripes at them if they pull the plug. what users
> are you trying to protect, ones to clueless to even run windows?
Precisely. Users of embedded devices don't expect to have to treat the
[EMAIL PROTECTED] said:
> In what way? A root fs readonly mount is usually designed to prevent
^^^
> the filesystem from being stomped on during the initial boot so that
> fsck can run without the filesystem being volatile. That's the only
> reaso
[EMAIL PROTECTED] said:
> Powering down a VCR whilst recording can damage the tape or even
> worse have the tap get jammed in the video. I have also had a TV die
> because it was unpowered from the mains without being switched off
> first.
> Sure, these things don't always happen -- but they so
[EMAIL PROTECTED] said:
> Many newer cell phones, even low spec ones, will have a software
> power switch (usually with a hardware override after about 5 seconds
> of continuous press). There are many other concessions that need to
> be made to power efficiency, like the ability to toggle power
[EMAIL PROTECTED] said:
> Also, if you care about memory usage, you're likely to be much better
> off using ramfs rather than something like "ext2 on ramdisk". You
> won't get the double buffering.
That'll be even more useful once we can completely configure out all
support for block devices
[EMAIL PROTECTED] said:
> I put it into generic_file_write. That covers most fs's it seems. The
> jffs guys are going to switch to generic_file_write soon
It's in CVS already. For 2.4, 'soon' == 'when Linus is ready to start taking
patches'
If you want it for 2.4-ac I can provide a patch whi
[EMAIL PROTECTED] said:
> While the topic is raised..., I've hacked up cramfs for linear
> addressing to kill the "double buffering" effiect. However as David
> mentions the block device support thing is an issue here. What is a
> reasonable way to allow a cramfs partition to access the dev
[EMAIL PROTECTED] said:
> What is the procedure for adding a new system call to the Linux
> kernel?
First: Convince people that it's necessary.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FA
On Tue, 9 Jan 2001, Arnaldo Carvalho de Melo wrote:
> --- linux-2.4.0-ac4/drivers/char/n_r3964.cTue Dec 19 11:25:34 2000
> +++ linux-2.4.0-ac4.acme/drivers/char/n_r3964.c Tue Jan 9 14:23:07 2001
> + restore_flags(flags);
/me scratches head...
Err is there any reason
On Tue, 9 Jan 2001, Linus Torvalds wrote:
> And this _is_ a downside, there's no question about it. There's the worry
> about the potential loss of locality, but there's also the fact that you
> effectively need a bigger swap partition with 2.4.x - never mind that
> large portions of the allocati
[EMAIL PROTECTED] said:
> The no-swap behaviour shoul dactually be pretty much identical,
> simply because both 2.2 and 2.4 will do the same thing: just skip
> dirty pages in the page tables because they cannot do anything about
> them.
So the VM code spends a fair amount of time scanning list
[EMAIL PROTECTED] said:
> In BIOS my USB keyboard works really poorly - it almost seems
> scancodes get dropped left and right. Ok, so I don't mind too much,
> i'm sure BIOS has a very limited driver. After booting Microsoft's
> offerring, it would work fine after it installs its driver. I al
[EMAIL PROTECTED] said:
> i prefer clear oopses and bug reports instead of ignoring them. A
> failed MSR write is not something to be taken easily. MSR writes if
> fail mean that there is a serious kernel bug - we want to stop the
> kernel and complain ASAP. And correct code will be much more re
[EMAIL PROTECTED] said:
> And what a pile of crud those patches are!! Instead of using the
> clean replacement interface for get_module_symbol, nvidia/
> patch-2.4.0-PR hard codes the old get_module_symbol algorithm as
> inline code.
Taking away get_module_symbol() and providing a replacement
[EMAIL PROTECTED] said:
> Q. With your suggested static method, what happens when Y initialises
>before X, calls inter_module_get, retrieves X's static data and
>starts to use it before X has initialised?
> A. Oops!
No. You'd explicitly only use the static registration when object X do
[EMAIL PROTECTED] said:
> So you want two services, one static for code that does not do any
> initialisation and one dynamic for code that does do initialisation.
> Can you imagine the fun when somebody adds startup code to a routine
> that was using static registration?
Oh come on. If you ch
On Fri, 12 Jan 2001, Keith Owens wrote:
> People need to realise that the problem is initialisation order,
> nothing more, nothing less. You have to determine and document the
> startup requirements for your code.
This is true. But I'd also agree with the implication which you probably
didn't m
[EMAIL PROTECTED] said:
> You just proved my point. It is extremely difficult to deduce the
> required initialisation order by reading an undocumented Makefile
> where the init order is implemented as a side effect of selection
> order. The existing method implies link order when none is requi
[EMAIL PROTECTED] said:
> No, I'm judging based on the fact that I found reports from people
> using NE2K-PCI with several cards as well as tulip-based cards
> (different driver) on abit BP6 as well as Gigabyte motherboards,
> mostly on 2.3.x/2.4.x kernels. I found some postings with these
> pro
[EMAIL PROTECTED] said:
> IRR for interrupt 19 is set, that means the IO APIC has sent the
> interrupt to a cpu but not yet received the corresponding EOI.
OK, but couldn't we reset it by sending an extra EOI when the drivers
decide that they've missed interrupts?
--
dwmw2
-
To unsubscribe
On Fri, 12 Jan 2001, Ingo Molnar wrote:
> okay - i just wanted to hear a definitive word from you that this fixes
> your problem, because this is what we'll have to do as a final solution.
> (barring any other solution.)
Patching 8390.c won't fix this for me. The only thing on IRQ19 when I saw
i
On Sat, 13 Jan 2001, Keith Owens wrote:
> Over emphasis for humorous effect. Must remember to add smiley.
Heh. But it does deserve to get into the fortune file.
> What this patch and David Woodhouse's comments show is that I need to
> look at a generic and safe mechanism for kernel/module symb
On Sat, 13 Jan 2001, Keith Owens wrote:
> BTW, modutils cannot automatically fill in upward references when a
> module is loaded. A reference is a use count, an automatic reference
> would be an automatic use count with no way of removing it. Code that
> calls upwards to a symbol must perform a
On 12 Jan 2001, Linus Torvalds wrote:
> In short, let's leave it out of a stable kernel for now, and add
> blacklisting of auto-DMA. Alan has a list. We can play around with
> trying to _fix_ DMA on the VIA chipsets in 2.5.x (and possibly backport
> the thing once it has been sufficiently battlet
On Sun, 14 Jan 2001, Keith Owens wrote:
> This is becoming more important as the kernel moves towards hot
> plugging devices, especially for binary only drivers. It is far better
> for the kernel community if modutils can say "cannot load module foo
> because its interfaces do not match the kern
On Sun, 14 Jan 2001, Keith Owens wrote:
> Note I said allowed, not supported. I refuse to support any binary
> only modules, my standard response to problems logged against binary
> modules is "remove them and reproduce the problem". Checking for ABI
> violations is not supporting binary module
On Sat, 13 Jan 2001, Linus Torvalds wrote:
> Somebody who can test it needs to send me a patch - I'm NOT going to apply
> patches that haven't been tested and that I cannot test myself.
This patch has worked for me and is obvious enough that I haven't bothered
to rewire my box to put the IBM dr
On 13 Jan 2001, Linus Torvalds wrote:
> You miss _entirely_ the reason why "get_module_symbol()" was removed,
> and why I will not _ever_ accept it coming back.
>
> Hint #1: get_MODULE_symbol().
> Hint #2: compiled in functionality.
Er,... forgive me if I'm being overly dense here, but I can't
On Sun, 14 Jan 2001, Linus Torvalds wrote:
> Note that previously there _were_ order dependencies. In fact, I consider
> it very tasteless to have modules that act differently on whether another
> module is loaded. I saw some arguments saying that this is th "right
> thing", and I disagree comple
On Sun, 14 Jan 2001, Linus Torvalds wrote:
> This is what "request_module()" and "kmod" is all about. Once we probe the
> hardware, the drievr itself can ask for more drivers.
>
> I completely fail to see the arguments that have been brought up for drm
> doing ugly things. The code should simply
On Sun, 14 Jan 2001, Linus Torvalds wrote:
> On Sun, 14 Jan 2001, David Woodhouse wrote:
> > That's the one flaw in the inter_module_get() stuff - we could do with a
> > way to put entries in the table at _compile_ time, rather than _only_
> > at run time.
> Ok,
[EMAIL PROTECTED] said:
> That is a lot of work for a very few special cases. OTOH, you could
> just add a few lines of __initcall code in two source files (which I
> did when I wrote inter_module_xxx) and swap the order of 3 lines in
> drivers/mtd/Makefile. Guess which alternative I am going f
[EMAIL PROTECTED] said:
> [Venkatesh Ramamurthy]
Your name is already in the headers of the mail you sent. There's no need to
repeat it.
> The LILO boot loader and the LILO command line utility should be changed
> for this.
> Is anybody doing this? -
There are patches available for the
[EMAIL PROTECTED] said:
> One reason why this may NOT ever make it into the kernel is that I
> know "kernel poking at devices" is really frowned upon.
A possible alternative is to specify drives by serial number.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-ke
[EMAIL PROTECTED] said:
> The one thing I don't know is... can the kernel mount the root fs if
> only given the uuid?
There are 2.2 patches to do it, which I think are now being dusted off and
resurrected. but scanning for UUID involves poking at every partition on
every available hard drive.
[EMAIL PROTECTED] said:
> Access is ok with kernel 2.2 even in a case when machine with 2.4
> kernel is masquerading host. It doesn't work with any port. Ping
> works.
Read the FAQ again. More carefully this time. Pay close attention to
section 14.2
http://www.tux.org/lkml/
--
dwmw2
-
To
[EMAIL PROTECTED] said:
> we need some kind of signature being written in the drive, which the
> kernel will use for determining the boot drive and later re-order
> drives, if required.
> Is someone handling this already?
It should be possible to read the BIOS setting for this option and
beha
[EMAIL PROTECTED] said:
> For Linux I think the right way to handle this is to have each
> (SA_SHIRQ) sharing capable interrupt handler return a TRUE or FALSE
> value indicating whether the interrupt belongs to the driver. In
> kernel/irq.c:handle_IRQ_event() check the return value. If after one
On Fri, 19 Jan 2001 [EMAIL PROTECTED] wrote:
> Many oopses appeared, among others gcc closed with signal 11.
>
> One output:
Read http://www.tux.org/lkml/#s4-3
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Pl
On Fri, 19 Jan 2001, John O'Donnell wrote:
> snpe wrote:
> > Is there ibcs2 or abi for kernel 2.4.x ?
>
> Been discussed - Check this out:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=97149702506290&w=2
Yeah - dusting it off and making it work in 2.5 is somewhere on my
ever-growing TODO li
On Sat, 20 Jan 2001, Linus Torvalds wrote:
> There's no no-no here: you can even create the "struct page"s on demand,
> and create a dummy local zone that contains them that they all point back
> to. It should be trivial - nobody else cares about those pages or that
> zone anyway.
>
> This is ve
On Mon, 22 Jan 2001, Rainer Mager wrote:
> I brought up this issue last month and had some response but as
> of yet my particular problem still exists. In brief, X windows dies
> with signal 11. I have done quite a bit of testing and this does not
> seem to be a hardware issue. Also, I have
[EMAIL PROTECTED] said:
> It says: IP-Config: No network devices available.
> a few lines below that the nic (3com 575) is detected. Of course it
> fails to do the nfs mount.
The kernel delays the initialisation of CardBus sockets to prevent it from
dying in an IRQ storm as soon as it registe
On Mon, 13 Nov 2000, David Hinds wrote:
> The i82365 and tcic drivers in the 2.4 tree have not been converted to
> use the thread stuff; as far as I know, the yenta driver is the only
> socket driver that works at all in 2.4.
>
> On Mon, Nov 13, 2000 at 09:52:30PM +, David
On Mon, 13 Nov 2000, Jeff Garzik wrote:
> It's purposefully not on Ted's critical list, the official line is "use
> pcmcia_cs external package" if you need i82365 or tcic instead of yenta
> AFAIK. However... fixing things and being able to support all pcmcia
> and cardbus adapters would be wonde
[EMAIL PROTECTED] said:
> Someone could make it a bit smaller by patching fs/jffs/interp.c and
> arch/ppc/xmon/xmon.c to use the kernel lib, rather than their own
> versions.
Makes sense to me. Patch attached. As an added bonus, this patch (not the
ctype change) also speeds up JFFS mounting by
[EMAIL PROTECTED] said:
> Umm.. Linus drivers dont appear to be SMP safe on unload
AFAIK, no kernel threads are currently SMP safe on unload. However,
the PCMCIA thread would be safe with the patch below, and we could fairly
easily convert the others to use up_and_exit() once it's available
Missing up_and_exit() which is required for killing kernel threads on
cleanup_module().
This patch also fixes JFFS and USB hub.c to use it.
Index: include/linux/kernel.h
===
RCS file: /inst/cvs/linux/include/linux/kernel.h,v
ret
[EMAIL PROTECTED] said:
> If somebody still has a problem with the in-kernel stuff, speak up.
I have an i82092AA evaluation board:
00:06.0 PCMCIA bridge: Intel Corporation 82092AA_0 (rev 02)
Flags: slow devsel, IRQ 27
I/O ports at 8400 [size=4]
I have three problems:
1. I ha
[EMAIL PROTECTED] said:
> For these two, it sounds to me like you need to be doing a PCI probe,
> and getting the irq and I/O port info from pci_dev. And calling
> pci_enable_device, which may or may not be a showstopper here...
Yep. The same code is already present in David Hinds' i82365.c,
[EMAIL PROTECTED] said:
> It should be possible to do the same thing with a nice simple
> concentrated PCI probe, instead of having stuff quite as spread out as
> it used to be.
That's the plan.
> As to why it doesn't show any ISA interrupts, who knows... Some of
> the PCI PCMCIA bridges need
Index: drivers/media/video/msp3400.c
===
RCS file: /net/passion/inst/cvs/linux/drivers/media/video/Attic/msp3400.c,v
retrieving revision 1.1.2.2
diff -u -r1.1.2.2 msp3400.c
--- drivers/media/video/msp3400.c 2000/11/15 12:15:02
On Sat, 18 Nov 2000, Andrew Morton wrote:
>
> This patch removes tq_scheduler from the kernel. All uses of
> tq_scheduler are migrated over to use schedule_task().
>
> Notes:
> - If anyone sleeps in a callback, then all other users of
> schedule_task() also sleep. But there's nothing new here
On Sun, 19 Nov 2000, Dan Hollis wrote:
> Writeprotect the flashbios with the motherboard jumper, and remove the
> cmos battery.
>
> Checkmate. :-)
Only if you run your kernel XIP from the flash. If you load it into RAM,
it's still possible for an attacker to modify it. You can load new code
into
[EMAIL PROTECTED] said:
> We applied a slightly different patch which is would not remove the
> pages out from under the thread, using semaphores instead.
> This patch isn't needed anymore. Thanks anyway.
Actually, the best fix is probably to get rid of the thread entirely and use
schedule_tas
[EMAIL PROTECTED] said:
> Nov 21 08:08:40 t kernel: hde: IBM-DTLA-307030, ATA DISK drive
> Nov 21 08:08:40 t kernel: hde: hde1 hde2 < hde5
> And then after a while it gets a DMA timeout and hangs hard.
You mean this?
hde: timeout waiting for DMA
ide_dmaproc: chipset supp
[EMAIL PROTECTED] said:
> 2.2.x and 2.4.0-xxx, do not share the same interrupt pin hack.
> Add the above stub to ide-pci.c near or at line 756 to look like 2.2,
> then retry and see if it fixes it. Then you bitch at Linus, not me,
> because it is a functional kludge, but a "kludge".
But:
[EMAIL PROTECTED] said:
> When it comes to the partition detection during bootup, udma4 or
> udma3 doesn't seem to matter. It passes approx. one out of ten times
> either way.
How have you made it use udma3 at bootup? Something like the patch below?
Index: drivers/ide/hpt366.c
===
On Tue, 21 Nov 2000, Johannes Erdfelt wrote:
> That that possible? usb_hub_events can block for a long time. That is why
> the kernel thread was needed. I'm not familiar with schedule_task enough
> to know if it can be used.
Ah. How long? At first glance, it didn't look to me as if it would slee
On Tue, 21 Nov 2000, Andre Hedrick wrote:
> No, if it doesn not hang and we get iCRC errors it will down grade
> automatically, but it is a transfer rate issue than it must be hard coded
> to force an upper threshold limit.
Do we downgrade gracefully, or do we just drop directly to non-DMA mode?
On Tue, 21 Nov 2000, Andre Hedrick wrote:
>
> Does that fix it?
WorksForMe(tm)
Grrr. I specifically went and read the HPT366 blacklist before buying my
shiny new hard drive.
> On Tue, 21 Nov 2000, David Woodhouse wrote:
> > Index: drive
[EMAIL PROTECTED] said:
> Installed kernel 2.4.0-test11 on my Debian Woody box today. Had no
> problem apart from getting PCMCIA to work. I have a PCI-PCMCIA adapter
> on my desktop PC, using the Cirrus Logic CL6729 chipset;
Linus got a bit carried away when stripping out all the CardBus suppo
[EMAIL PROTECTED] said:
> Multiple seconds in the worst case.
Well, I think the PCMCIA socket drivers would be happy with that. Depends
what akpm also added to the list of tasks, and whether Linus actually puts
that patch into test12.
Probably best to leave it for now and think about it in
[EMAIL PROTECTED] said:
> Is there a technical reason for this? Not that I know of; but then I
> also cannot think of a good reason for wanting, say, the generic code
> built in but the controller support as modules. I do see reasonable
> arguments for all-builtin or all-modules.
register_ss_
[EMAIL PROTECTED] said:
> Nothing which sleeps for very long - mainly serial drivers which
> queue a call to tty_hangup(), which immediately queues _another_
> tq_scheduler call to do_tty_hangup (Why? Heaven knows).
Not so much worried about that. More about how sensitive they would be to
so
[EMAIL PROTECTED] said:
> Ah. No, I don't think it would be polite to cause TTY hangup
> processing to be deferred for this long. I'd suggest that the policy
> be "scheduled tasks can't sleep". I guess kmalloc(GFP_KERNEL) is
> acceptable because the system is already running like a dog if thi
[EMAIL PROTECTED] said:
> > |> Can't we change that to :
> > |> #error "Udelay..."
> >
> > No.
>
> ?? I think I'm missing something here.
> preprocessor stuff is done too early for this
We were talking about
#if 0
/* Don't turn this on, fix your code instead */
void __bad_udelay(int c)
{
#e
On Fri, 24 Nov 2000, Russell King wrote:
> The recent patch in 2.4.0-test11 causes MTD to oops the kernel:
Fixed in my tree. That and other things will be fixed when I flush the
latest CFI code to Linus - probably quite soon.
The inter_module_ stuff has introduced link order dependencies too. I
On Sun, 26 Nov 2000, Frank van Maarseveen wrote:
> Nov 25 23:15:12 mimas cardmgr[342]: exiting
> Nov 25 23:15:14 mimas kernel: Trying to free nonexistent resource <03e0-03e1>
> Nov 25 23:15:14 mimas kernel: unloading PCMCIA Card Services
This is normal behaviour. It's buggy but it's harm
On Sun, 26 Nov 2000, Jeff Epler wrote:
> How can you have the console on a modularized device?
You can have more than one console device. Only the primary device needs
to be present at boot time. Actually, I'm not sure even that has to be
present.
Since I added unregister_console() a long time
Index: kernel/module.c
===
RCS file: /inst/cvs/linux/kernel/module.c,v
retrieving revision 1.1.1.1.2.11
diff -u -r1.1.1.1.2.11 module.c
--- kernel/module.c 2000/11/10 14:56:37 1.1.1.1.2.11
+++ kernel/module.c 2000/11/27 13
[EMAIL PROTECTED] said:
> Not necessarily - it all depends on what your driver does. In many
> cases, supporting 2.2 and 2.4 is easy, and all you need are a few
> #if's. It's certainly much better to have a dozen or so #if's
> sprinkled throughout the code than to have two separate source tree
This code in fs/fat/file.c::fat_get_block() is getting triggered when I
run wine:
if (iblock<<9 != MSDOS_I(inode)->mmu_private) {
BUG();
return -EIO;
}
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
Haven't tried test12-pre7 yet. Is enabling bus mastering likely to make
this magically go away? I doubt it.
This happened when trying to run excel under wine. Dual Celeron with
CONFIG_USB_UHCI.
NMI Watchdog detected LOCKUP on CPU1, registers:
CPU:1
EIP:0010:[]
Using defaults from ksy
Who wants this?
invalid operand:
CPU:1
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax: 0039 ebx: cdfae6c0 ecx: c0288c4c edx: 0001
esi: c14b0c40 edi: ccd55c80 ebp: cf1a4560 esp: cb235e5c
ds: 0018 es: 0018 ss: 0018
Process gn
My home directory lives on a SunOS 4.1.4 server, which helpfully expands
16-bit UIDs to 32 bits as signed quantities, not unsigned. So any uid above
32768 gets 0x added to it.
This patch adds a mount option to the Linux NFS client to work round this
brokenness. I haven't updated the N
[EMAIL PROTECTED] said:
> I'm sure that once the FSF is willing to step up, there will be lots
> of supporters and sponsors to finance this.
Far smaller companies have _already_ got away with not only violating the
Linux kernel's GPL, but blatantly encouraging their customers to do so.
Why sh
[EMAIL PROTECTED] said:
> nfs_file_cred() <- nfs_create_request() <- nfs_update_request() <-
> nfs_updatepage() <- nfs_commit_write() <- generic_file_write() <-
> nfs_file_write() <- write(2).
> Fscked credentials during write(2) on NFS...
Is this known and fixed, or just known?
--
dwmw2
-
[EMAIL PROTECTED] said:
> - convert drivers to new PCI API
Don't bother with drivers/char/applicom.c - I've already done it, just
waiting to borrow the hardware again to test it.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
[EMAIL PROTECTED] said:
> M-Systems is in the process of creating a new driver that works as a
> module and contains no GPL code.
A modular driver for rootfs doesn't really strike me as being particularly
useful on an embedded system where you're trying to save every byte
possible, and you d
[EMAIL PROTECTED] said:
> Since upgrading from 2.4.0-test6 to 2.4.0-test7 I have noticed I
> can't connect to some webs, www.amazon.com, www.linuxtoday.com...
> (trying telnet www.linuxtoday.com 80 returns connection refused). It
> works with 2.2.X series, 2.4.0-test6 and bellow... It has b
[EMAIL PROTECTED] said:
> It's the update to gcc2.96 causing this problems?? How can i get to
> compile the kernel?
You cannot safely compile even 2.4 kernels with gcc-2.96 on any platform, as
far as I'm aware. It's an insane thing to do. Use a sensible compiler.
--
dwmw2
-
To unsubscribe f
[EMAIL PROTECTED] said:
> Which Linux companies are profitable? **NONE**. The only people
> making money are hardware vendors and it's a model like SUN's, where
> you get a free "machine driver" with every system you buy.
And nobody has explained to me why these are _bad_ things.
--
dwmw
[EMAIL PROTECTED] said:
> So it seems to be a bug at least in terms of timing. Unfortunately I
> only got about 4 replies to the patches that touched 20+ drivers. I
> suppose I should just hassle maintainers until they fix it or tell me
> where I've gone wrong ...
Actually, I was quite happy c
[EMAIL PROTECTED] said:
> > If there's other stuff on the run queue, it won't return immediately,
> > will it?
> It most likely will return immediately.
Oh well in that case it ought to task its task to something other than
TASK_RUNNING...
> > Otherwise, it would be TASK_UNINTERRUPTIBLE.
>
[EMAIL PROTECTED] said:
> We used to have the iBCS2 project, and I was actually considering
> making it part of the standard kernel when it started becoming a
> non-issue simply because there started to be more native Linux
> programs than iBCS2 programs.
Actually, you seemed to be considering
On Fri, 8 Sep 2000, Andrew Burgess wrote:
>
> > >Oops from 2.2.17 (some more before this, but it went offscreen):
> ...
> > You need to capture and decode the first oops. Compile a kernel with a
> > serial console and capture the oops log on a second machine.
>
> Or set your console for more
[EMAIL PROTECTED] said:
> I have to admit, the thought hadn't occurred to me to do that. It
> almost sounds like a good idea... after all the stub can't be used if
> no modules can be loaded. Are you thinking, then, that the stub can't
> be used by compiled in (ie non-module) code? Or am I misu
[EMAIL PROTECTED] said:
> Ah... I did misunderstand you. I thought you meant CONFIG_MODULES in
> general, which'd be okay - obviously, if module support is disabled,
> you can't load a module anyway.
Well actually, that's not strictly true. But it is fair to say that if
you're hacking new code
[EMAIL PROTECTED] said:
> But where do I get the other argument (struct pt_regs *) from? A
> normal Linux syscall does not appear to have access to such a beast...
With difficulty. A normal syscall wouldn't generally go through the lcall7
handler. Some of the ABI/iBCS code gets access to the s
> David Howells <[EMAIL PROTECTED]> wrote:
> > Now there's an idea... have the kernel autoload modules based on a
> > particular syscall number being handled in that module. Madness
> > *grin*.
[EMAIL PROTECTED] said:
> No more madness than kmod loading a module called char-major-10-135
> for /d
[EMAIL PROTECTED] said:
> Shared library linkage brings you into the same grey area that binary
> only kernel modules fall into, this means it's risky and this is
> almost certainly how the GCC team views this situation.
But how much work would it require to do so? If your theoretical vendor o
[EMAIL PROTECTED] said:
> I didn't know how to get hold of a "struct pt_regs*" till someone sent
> me a message this morning
Ah. I didn't realise you wanted the struct pt_regs for any purpose other
than to pass to the lcall7 handler - and I was no longer using the lcall7
handler in the sys_win
[EMAIL PROTECTED] said:
> Note that with most versions of gcc this is all a complete non-issue,
> as most versions of gcc will _always_ inline a function that the user
> has asked to be inlined. So the issue seldom actually comes up.
I thought that 'extern inline' was in fact the intended usage
[EMAIL PROTECTED] said:
> Linus,
> Where do architecture maintainers stand when they don't submit their
> problems to linux-kernel or the great Ted Bug List(tm)?
Up against the wall so we can shoot them?
:)
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
[EMAIL PROTECTED] said:
> I can't control somebody else's use of `hwclock` or even some future
> kernel module.
What you actually need to do is use the same spinlock as other users of the
RTC hardware do.
extern spinlock_t rtc_lock;
It is exported to modules for this very reason.
--
dwmw2
[EMAIL PROTECTED] said:
> There is no such exported variable in the 'stable' kernel tree:
Then there should be, and the RTC accesses in 2.2 are probably racy.
In which case, feel free to provide Alan with a patch for 2.2.18.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscrib
[EMAIL PROTECTED] said:
> The only other users are 8390.h and a couple of mtd things. I don't
> see why this stuff cannot be handled in userspace with /etc/
> modules.conf ...
Patch please :)
Either you'll see, or I'll owe you a beer. I'm happy either way.
> should get_module_symbol() die ?
[EMAIL PROTECTED] said:
> 2.2.17 should be able to do.
Cool. drivers/char/rtc.c needs to use it too. Then you need to pester Alan
till he puts it in 2.2.18-pre-de-jour :)
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EM
[EMAIL PROTECTED] said:
> You want to patch /drivers/char/rtc.c ?? If you have a later kernel
> than me, it would be helpful. Just apply my patch than do the rtc.c.
/me looks at his TODO list.
Not really.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
201 - 300 of 2231 matches
Mail list logo
