I am attempting to write an init replacement that is capability-smart.
Though I'm pleased that prctl() lets me keep capabilities across a
setreuid(), maintaining caps over execve() seems impossible to do right.
I currently see a few options:
- use the CLOEXEC-pipe hack that execcap uses (
I know this has been reported on the list recently, but I think I can
provide better detail. I'm running 2.4.2 with atyfb on a K6-2/266
running at 250. This system has no history of clock problems.
adjtimex-1.12 --compare gives me "2nd diff" readings of -0.01 in quiescent
conditions.
flipping co
2.4.2 worked OK, but I needed loopback also, so I tried 2.4.2-ac7.
I get the "uncompressing... Booting" line, and it hangs there
(I let it sit for 30s to be sure).
System: AMD K6-2/266, ATI Mach64, oldBusLogic SCSI card, almost
evreything compiled as modules.
I will try ac-8 once it shows up on
A couple of days ago, I reported that 2.4.2-ac7 was hanging on boot on
my k6-2 machine. I compiled ac-8, but turned odd UP_APIC, and it
worked (I vaguely remember some APIC-related hangs reported in the
past). If this is a new problem, I can narrow it down with a few
recompiles.
-Eric
-
To unsub
I have been using 2.4.0-ac20 for about a week, and today suddenly got a slew of
messages:
EXT2-fs error (device ide0(3,1)): ext2_new_block: Free blocks count corrupted for
block group 43
while copying the mozilla tree (a great way to stress out a filesystem! :)). This is
the first such
proble
These oopsen were invoked by a normal shell script. Hope you can make
some use of it. Processor is a K6/2.
-Eric
--
ksymoops 2.4.1 on i586 2.4.2-ac23. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.2-ac23/ (defa
This ooops happened while trying to nfsboot a 386, and restarting nfsd
halfway through the boot process. I bet it's not a common problem...
Server is 2.4.2-ac23, client (the Oopser) is 2.4.2-ac24.
The oops is partial because I had to hand-copy from the console, and
it blanked after a few minutes
2.4.2-ac23 nfsroot on a 386SX/20 with 6Mb RAM
On boot to single user, 'ls' and 'ls -l' work fine.
After mounting /proc, 'ls' still works, but 'ls -l' fails
with SIGILL after reading /etc/timezone (so says strace).
Unmounting /proc fixes the problem. Unmounting /dev doesn't.
I also, just now, h
On Tue, Mar 27, 2001 at 09:09:24AM -0500, Brian Gerst wrote:
> >
> > The problems are varied enough that I suspect bad hardware, but would
> > flaky RAM cause such similar failures repeatedly? And is there a way
> > to test RAM explicitly?
> >
> > Any tips appreciated, either to me ([EMAIL PROTE
On Tue, Mar 27, 2001 at 09:22:19AM -0500, Brian Gerst wrote:
> Try running ls under gdb and find out what instruction is causing SIGILL
> (illegal opcode). It is possible that it was compiled to use
> instructions available only on later processors, or it could potentially
> be a bug in the math
On Wed, Mar 28, 2001 at 10:09:11AM -0800, Ulrich Drepper wrote:
> Eric Buddington <[EMAIL PROTECTED]> writes:
>
> > OK. Context again (since I clipped preceding notes): 386SX/20 nfsroot,
> > getting SIGILL on lots of processes, math emulation is enabled, ls and
>
OK, I know this is bizarre and probably some goof on my part, but it
is just too weird for me to guess at further:
My program write()s 2- and 4- byte chunks or data to a file (for a WAV
header). When the data being written contains an 0xff byte, it is
apparently written to disk as 2 bytes: 0x81ff
My apologies for bothering the list with this cool-sounding but bogus
problem; I only sent it accidentally (I discovered my mistake while
writing the original) and followed with a retraction which I stupidly
sent to the old rutgers address. Wish I had sent the original there,
too.
I was fooled by
On Mon, Jan 15, 2007 at 07:27:56PM +, David Hollis wrote:
> Do you happen to have a Rev. B1 DLink adapter? If so, the only change
> that was put in (PHY Select fix) should actually make these devices
> work. Can you check the top of the ax88772_bind() call in your file and
> see if it has thi
On Mon, Jan 15, 2007 at 08:32:17PM +, David Hollis wrote:
> Interesting. It would really be something if your devices happen to
> work better with 0. Wouldn't make much sense at all unfortunately. If
> 0 works, could you also try setting it to 2 or 3? The PHY select value
> is a bit field w
On Wed, Jan 17, 2007 at 07:00:48AM -0500, David Hollis wrote:
> > 'rmmod asix' takes a really long time (45-80s) with any setting, and
> > sometimes coincides with ksoftirqd pegging (99.9% CPU) for several
> > seconds.
>
> This I haven't seen before. Does it occur even when the device is able
> t
Kernel 2.6.19-rc6-mm2 on an Athlon XP gave me the following Oops when
unplugging a USB device. I an usually plug and unplug devices without
trouble, so this is probably not easily repeatable.
-Eric
--
[1742504.966893] usb 1-6.4.
2.6.20-mm2 #1 Mon Feb 26 13:16:04 EST 2007 i686 unknown
I have an external USB drive (WD MyBook 5000YS), which I use for backups.
When I try to back up to it, it works for a while, but inevitably
starts resetting like mad, gives I/O errors, and then (here's the
problem), the softdog module reboot
On Tue, Feb 27, 2007 at 01:49:40PM -0800, Pete Zaitcev wrote:
> However, the main issue here is the OOM with all the dirty data.
> We saw that before. For some weird reason, ext3 is especially good
> at producing the immense amounts of write-out. Are you on ext3 or
> VFAT on that drive?
Reiser4.
On Sun, Feb 04, 2007 at 11:00:05AM +0100, Thomas Hellstr?m wrote:
> Eric,
> Sorry for the breakage. Can you try the attached patch and see if it
> fixes the problem.
>
> /Thomas
Thomas,
Thanks! That seems to fix it:
[drm] Initialized drm 1.1.0 20060810
ACPI: PCI Interrupt :01:00.0[A] -> GS
While repeatedly recompiling and restarting xorg-server-1.1.1, I
managed to generate the following BUG. Kernel is 2.6.20-rc6-mm3, video card is
01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 Pro Ultra TF
(prog-if 00 [VGA])
-Eric
--
BUG: unable t
On Sat, Feb 03, 2007 at 04:22:17PM -0500, Lee Revell wrote:
> On 2/3/07, Eric Buddington <[EMAIL PROTECTED]> wrote:
> >EIP:0060:[<>]Tainted: G M VLI
> >EFLAGS: 00013246 (2.6.20-rc6-mm3 #1)
>
> The "M" taint flag indicates that a ma
On Sun, Feb 04, 2007 at 10:20:29AM +1100, Dave Airlie wrote:
> What AGP chipset do you have? it looks like it might be caused by the
> AGP changes for TTM..
lspci:
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 741/741GX/M741 Host (rev
03)
00:01.0 PCI bridge: Silicon Integrated Systems [S
Machine: Linux <...> 2.6.20-rc3-mm1 #2 Mon Jan 8 00:24:59 EST 2007 i686 unknown
In normal (light) use, I experienced a long (~20s?) freeze, and errors
regarding hdc appeared in dmesg, along with the BUG. SMART on hdc
doesn't report any errors except a bad SMART checksum (I think that
may have been
The following problem occured on an Athlon64 X2 under 2.6.20-rc4-mm1,
but not 2.6.20-rc3-mm1.
I'm using two D-Link DUB-E100 USB ethernet adapters, using the 'asix'
driver. When I upgraded to 2.6.20-rc4-mm1, they were still recognized,
but various ifconfig operations on them (up/down, changing IP)
Kernel 2.6.20-mm2 on an Athlon XP.
Caveat: I know my USB cabling may cause the initial failure, but I
think the system should be failing more gracefully.
After hours of backing up to my external USB drive, I see in dmesg:
APIC error on CPU0: 00(02)
APIC error on CPU0: 02(02)
APIC error on CPU0:
On Mon, Mar 05, 2007 at 02:17:28AM -0800, Andrew Morton wrote:
> > On Tue, 27 Feb 2007 09:06:21 -0500 Eric Buddington <[EMAIL PROTECTED]>
> > wrote:
> > 2.6.20-mm2 #1 Mon Feb 26 13:16:04 EST 2007 i686 unknown
> >
> > I have an external USB drive (WD MyB
On Tue, Mar 06, 2007 at 01:34:41PM -0500, Alan Stern wrote:
> The stack trace didn't include the khubd process at all. Probably that
> means it had already died.
No, it's still there. I ran 'echo t >/proc/sysrq-trigger' again, and
khubd did not show up in dmesg:
-bash-2.05b# echo t >/proc/sysrq
On Wed, Mar 07, 2007 at 11:03:21AM -0500, Alan Stern wrote:
> On Tue, 6 Mar 2007, Eric Buddington wrote:
>
> > On Tue, Mar 06, 2007 at 01:34:41PM -0500, Alan Stern wrote:
> > > The stack trace didn't include the khubd process at all. Probably that
> > > mea
On Wed, Mar 07, 2007 at 03:22:05PM -0500, Alan Stern wrote:
> On Wed, 7 Mar 2007, Eric Buddington,,, wrote:
>
> > > > So SysRq-t doesn't show anything about khubd, and SysRq-p doesn't give
> > > > me anything at all. What else can I try?
>
> How abou
30 matches
Mail list logo
