On Mon, Aug 24, 2009 at 12:03:40PM -0300, Nenhum_de_Nos wrote:
hail,
portmaster is great, but this is keeping me from using it.I want to fire a
portmaster -af and let it there until its done. for every package it asks
this. is ther any way to make it not ask ? delete and go ahead ?
With the testcode I put on
http://www.stack.nl/~marcolz/FreeBSD/pr-bin-40278/40278.c I can
reproduce it on FreeBSD 4.11:
output on 4.11-STABLE
--
Init: mktime: 1014944400 Fri Mar 1 02:00:00 CET 2002
1: mktime: 4294967295 Fri Apr 0 02:00:00 CET 2002
Init: mktime: 1014944400 Fri Mar 1
On Sat, Nov 17, 2007 at 12:14:46PM +0100, Marc Olzheim wrote:
For the MACHINE_ARCH == amd64 ${CC} != icc case,
the -mno-sse3 flag that *is* set for MACHINE_ARCH == i386, is not set.
I don't think the current gcc actually uses sse3 anywhere in the kernel
compile, as my kernels are working
On Wed, Nov 14, 2007 at 03:08:20PM +0100, Marc Olzheim wrote:
today I updated from 6.2-RELEASE-p8 to 7.0-BETA2 as well.
I've ran into the same problem with the password input to GELI on boot
time.
Chars are showing up after several keypresses.
After removing the new dcons
On Sat, Nov 17, 2007 at 12:14:46PM +0100, Marc Olzheim wrote:
For the MACHINE_ARCH == amd64 ${CC} != icc case,
the -mno-sse3 flag that *is* set for MACHINE_ARCH == i386, is not set.
I don't think the current gcc actually uses sse3 anywhere in the kernel
compile, as my kernels are working
For the MACHINE_ARCH == amd64 ${CC} != icc case,
the -mno-sse3 flag that *is* set for MACHINE_ARCH == i386, is not set.
I don't think the current gcc actually uses sse3 anywhere in the kernel
compile, as my kernels are working as normal, but for the sake of
completeness, I suggest the attached
On Sun, Nov 11, 2007 at 03:54:24PM +0100, Marc Olzheim wrote:
today I updated from 6.2-RELEASE-p8 to 7.0-BETA2 as well.
I've ran into the same problem with the password input to GELI on boot time.
Chars are showing up after several keypresses.
After removing the new dcons driver from my
On Thu, Nov 08, 2007 at 05:09:34PM +0100, Thorsten Trampisch wrote:
Hello,
today I updated from 6.2-RELEASE-p8 to 7.0-BETA2 as well.
I've ran into the same problem with the password input to GELI on boot time.
Chars are showing up after several keypresses.
After removing the new dcons
On Wed, Nov 07, 2007 at 10:41:40AM +0100, Karsten Rothemund wrote:
On Tue, Nov 06, 2007 at 04:35:24PM +0100, Marc Olzheim wrote:
Hi.
I can't get the kernel to accept my passphrase at boot time.
What kind of passphrase do you use? I had the same problem until I
realized, that my
Hi.
I can't get the kernel to accept my passphrase at boot time.
Excerpt from dmesg:
...
FreeBSD 7.0-BETA2 #0: Tue Nov 6 15:06:03 UTC 2007
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/LAPCAT
Preloaded elf kernel /boot/kernel/kernel at 0x808a5000.
Preloaded elf obj module
On Mon, Oct 31, 2005 at 05:01:50PM +0100, Marc Olzheim wrote:
Is the 'VM/VFS overruns' item still a problem? That was likely fixed a
couple of months ago. If not then it's definitely something that I'll
track for the 6.1 release.
I'll retest that one, but it wasn't fixed yet
On Tue, Nov 01, 2005 at 06:40:42AM +0600, Max Khon wrote:
Linking against -lthr (or even -lc_r!) instead of -lpthread solves gdb
The program no longer exists. problem for me on RELENG_6.
Well, yes, but that's not the same. While running on M:N KSE, all sorts
of locking needs to be correct,
On Tue, Nov 01, 2005 at 06:33:21PM +0600, Max Khon wrote:
Hi!
On Tue, Nov 01, 2005 at 12:29:00PM +0100, Marc Olzheim wrote:
Linking against -lthr (or even -lc_r!) instead of -lpthread solves gdb
The program no longer exists. problem for me on RELENG_6.
Well, yes, but that's
On Thu, Oct 27, 2005 at 12:05:07PM -0600, Scott Long wrote:
Everyone is still welcome to update their sources on the RELENG_6_0
branch and provide feedback for the next 48 hours or so. The release
will likely be announced by the end of the weekend or early next
week, at the latest.
On Mon, Oct 31, 2005 at 08:36:42AM -0700, Scott Long wrote:
Anyone having updates for my showstopper page, please, notify me...
http://www.stack.nl/%7Emarcolz/FreeBSD/showstoppers.html
The pty problem is likely a side effect of known locking problems with
ttys and ptys in general. This
On Thu, Jul 21, 2005 at 11:45:33AM +0200, Marc Olzheim wrote:
Having enough opportunities to do crash recovery with kern/83375 open
and some of my services not yet moved back to FreeBSD 4, I noticed that
often it crashes just after (or perhaps during) mirroring of a directory
tree
On Mon, Aug 01, 2005 at 10:48:04PM +0800, Xin LI wrote:
Hi, Marc,
On Mon, Aug 01, 2005 at 10:58:08AM +0200, Marc Olzheim wrote:
Ok, this time it's worse; Trying to startup single user, gives:
WARNING: / was not properly dismounted
start_init: trying /sbin/init
WARNING: R/W mount
On Mon, Aug 01, 2005 at 11:44:07PM +0800, Xin LI wrote:
After fsck telling me it's all ok, when I reboot (even after being up a
couple of minutes), I still get the same messages now.
Hmm... Could you please confirm that the final vnode sync has been
completed?
Hmm, I'm not sure...
I know
On Sat, Jul 23, 2005 at 08:43:00AM +0100, Dick Davies wrote:
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/pxe/article.html
Heheh...
This needs updating; only 2 of the vnconfig references have been updated
to mdconfig.
Marc
pgpYywe8nwJob.pgp
Description: PGP signature
On Thu, Jul 21, 2005 at 10:56:54AM +0200, Eirik verby wrote:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 00
fault virtual address = 0x1c
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc0620b5f
stack pointer =
Hi.
Having enough opportunities to do crash recovery with kern/83375 open
and some of my services not yet moved back to FreeBSD 4, I noticed that
often it crashes just after (or perhaps during) mirroring of a directory
tree. The mirroring involves creating a directory with in it 80
subdirectories
On Wed, Jul 20, 2005 at 08:43:33PM -0700, Alexey Yakimovich wrote:
My advice to FreeBSD release engineering team:
- do more testing;
- have it tested with hardware what was published in Hardware Notes;
- do not release it for production if it is not in production quality;
- reread again what
On Thu, Jul 21, 2005 at 08:29:47PM +0930, Daniel O'Connor wrote:
I think the best way to rectify this is to test RC candidates on YOUR
hardware.. This finds the bugs you need fixed at a time when people are very
receptive to fixing them.
It's not realistic for the release engineer to test
Robert,
First, thank you for your clear reply.
90% of useful FreeBSD testing happens when large FreeBSD consumers take
release of FreeBSD and deploy them in their testbeds and real-world
environments, and find the bugs through the application of high levels of
load and obscure hardware
On Thu, Jul 21, 2005 at 02:19:23PM +0200, Eirik verby wrote:
If you cause syslogd not to send any output to /dev/console, does
the
problem go away?
I'm afraid to say it doesn't
Please, could you add:
options DDB #Enable the kernel debugger
options DDB_NUMSYM
On Tue, Apr 19, 2005 at 10:38:08AM +0200, Marc Olzheim wrote:
The problem is with the periodic SMM interrupt and the bios.
The attached program (ich-periodic-smm-disable.c) will fix the problem.
For more information on what it does, see the Intel ICH3 datasheet.
compile as 'gcc
On Thu, Jul 21, 2005 at 01:20:49PM +0100, Robert Watson wrote:
I know FreeBSD 5 was a strange exception in the relase scheduling and
that a lot has been learned from it for the future and I'm certainly not
unthankful for all the work that's done, but I'd like a clear answer on
what to do
On Wed, Jun 08, 2005 at 08:04:28PM +0200, Marc Olzheim wrote:
I remember 5.2.1 panicking left and right, on several machines, it was
completely unusable. Maybe we just live in different universes.
Me too, but a lot has changed since 5.2.1 which at the time was I think was
called
On Tue, Jul 19, 2005 at 11:28:03AM +0200, Marc Olzheim wrote:
On Wed, Jun 08, 2005 at 08:04:28PM +0200, Marc Olzheim wrote:
I remember 5.2.1 panicking left and right, on several machines, it was
completely unusable. Maybe we just live in different universes.
Me too, but a lot has
On Fri, Jul 15, 2005 at 08:05:23AM -0400, Kris Kennaway wrote:
Ok, even non-SMP 7-CURRENT crashes on it, so I do not believe that I'm
the only one seeing this...
You're not..as noted, it's been widely reported.
Could you give me any pointers to where this has been discussed before ?
Would
On Tue, Jul 19, 2005 at 01:53:14PM +0200, Marc Olzheim wrote:
On Fri, Jul 15, 2005 at 08:05:23AM -0400, Kris Kennaway wrote:
Ok, even non-SMP 7-CURRENT crashes on it, so I do not believe that I'm
the only one seeing this...
You're not..as noted, it's been widely reported.
Could you
On Tue, Jul 19, 2005 at 11:46:18AM +0200, Marc Olzheim wrote:
Since I can't seem to keep any recent RELENG_5 kernel up and running
atm. I'd change my viewpoint to run 5.4 and apply all necessary
stability patches yourself. I'll prepare a patchset...
ARGH, nevermind, 5.4-release-p4 crashes
On Thu, Jul 14, 2005 at 01:44:04PM -0400, Kris Kennaway wrote:
The -CURRENT traces are very different from these, but I don't have
comconsole on the -CURRENT machine.
Thanks.
Since I get plenty of opportunities to fiddle in the debugger now,
because this happens a lot (we use screen a
On Fri, Jul 15, 2005 at 11:40:27AM +0200, Marc Olzheim wrote:
On Thu, Jul 14, 2005 at 01:44:04PM -0400, Kris Kennaway wrote:
The -CURRENT traces are very different from these, but I don't have
comconsole on the -CURRENT machine.
Thanks.
Am I really the only one seeing this ? Or has
On Wed, Jul 13, 2005 at 02:41:18PM -0400, Kris Kennaway wrote:
Make sure you recompile any modules when activating INVARIANTS, or
you'll get panics.
Of course... make buildkernel and make installkernel do that for me... ;)
Not if you are using third party port modules.
Well, I'm
On Mon, Jul 11, 2005 at 04:32:16PM +0200, Marc Olzheim wrote:
On Sun, Jul 03, 2005 at 10:38:58AM +0200, Philippe PEGON wrote:
The panic appears to be an instance of a known bug in 5.4 (and
INVARIANTS will not fix it, but may just delay the inevitable by
changing timings). See Doug White's
On Wed, Jul 13, 2005 at 08:00:31AM -0400, Kris Kennaway wrote:
Stress testing this gives me instant fatal trap 12 on both 11 juli's
CURRENT and RELENG_5.
I'll file a PR.
Make sure you recompile any modules when activating INVARIANTS, or
you'll get panics.
Of course... make
On Sun, Jul 03, 2005 at 10:38:58AM +0200, Philippe PEGON wrote:
The panic appears to be an instance of a known bug in 5.4 (and
INVARIANTS will not fix it, but may just delay the inevitable by
changing timings). See Doug White's recent emails which point to a
patch you should test.
If you
Somehow, this sounds familiar, i.e.: the lock cmpxchgl:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x1c
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc05160c3
stack pointer =
On Fri, Jul 01, 2005 at 12:14:58PM +0200, Marc Olzheim wrote:
Somehow, this sounds familiar, i.e.: the lock cmpxchgl:
Fatal trap 12: page fault while in kernel mode
...
Stopped at 0xc05160c3 = knote+0x27:lock cmpxchgl
%ecx,0x1c(%edx)
Somehow I think I solved this last time
On Fri, Jul 01, 2005 at 12:41:39PM +0200, Marc Olzheim wrote:
On Fri, Jul 01, 2005 at 12:14:58PM +0200, Marc Olzheim wrote:
Somehow, this sounds familiar, i.e.: the lock cmpxchgl:
Fatal trap 12: page fault while in kernel mode
...
Stopped at 0xc05160c3 = knote+0x27:lock
On Tue, Jun 21, 2005 at 09:00:05PM +0700, Khanh Cao Van wrote:
Peter Jeremy tell me that I have to update libpthread to be able to
install JDK 1.4 on freeBSD 4.7 . But I could not find out what ports
contain that lib . Help me if you know .
There is no /usr/src/lib/libpthread for FreeBSD-4.x
On Mon, Jun 20, 2005 at 10:53:19AM +0200, Eirik verby wrote:
I know enough not to call this a confirmation, but disabling
dummynet did indeed allow me to finish the backup. I never made it
past 15GBs before, now the full 19GB tar.gz file is done, and the
boxes are both still running. The
On Mon, Jun 20, 2005 at 06:29:31PM +0200, Eirik verby wrote:
Hmm, does that solve kern/79208 for you as well by any chance ?
Seems not.
Now, how do I get my box back to life? ;)
Hmm, Sorry 'bout that... :-/
Marc
pgpAHJk8H7OoT.pgp
Description: PGP signature
On Wed, Jun 08, 2005 at 10:44:07PM -0500, Vulpes Velox wrote:
Personnally, when upgrading from 4.x to 5.x, we ran into the
following 3 issues that are still not fixed in 5.4:
kern/80617:
Hangup writing large blocks to NFS mounted FS(Patches available)
Not exremely important: just
On Fri, Jun 10, 2005 at 11:32:14AM +0200, Goran Gajic wrote:
Latest change to uipc_socket2.c fixed my problem with start of apache2 in
chroot enviroment. Whenever I reboot 5.4 I was forced to manualy do:
chroot /CHROOT/APACHE /usr/local/apache2/bin/httpd -D SSL
no matter I already had that
On Mon, May 30, 2005 at 11:21:37AM +0100, Robert Watson wrote:
Great. I'll MFC this in a week or so assuming that there are no reports
of problems with the patch in HEAD. Thanks for the clear and concise bug
report, and sorry about taking so long to get this fixed!
Haven't had any problems
On Wed, Jun 08, 2005 at 01:42:45PM -0400, Mike Tancsa wrote:
I remember 5.2.1 panicking left and right, on several machines, it was
completely unusable. Maybe we just live in different universes.
Me too, but a lot has changed since 5.2.1 which at the time was I think was
called a preview.
On Tue, Jun 07, 2005 at 12:03:41PM +0200, Francois Tigeot wrote:
On Tue, Jun 07, 2005 at 12:03:01AM +0200, Torfinn Ingolfsen wrote:
What are people using for remote X displays on amd64 machines?
Stock X is sufficient.
That's really not a substitue for nxserver's performance... Assuming
On Fri, May 27, 2005 at 04:57:57PM +0200, Marc Olzheim wrote:
Could you try the attached patch and see if it helps matters? This is
a slight shot in the dark but closes at least two races in the
transition of socket state with respect to socket buffer state.
Yes! This fixes
On Fri, May 27, 2005 at 12:47:28PM +0100, Robert Watson wrote:
Hmm. I'm unable to reproduce this on local SMP hardware, although I can
see at least one way that the race could occur. Could you try the
attached patch and see if it helps matters? This is a slight shot in the
dark but
On Fri, May 27, 2005 at 03:44:41PM +0200, Marc Olzheim wrote:
Could you try the attached patch and see if it helps matters? This is
a slight shot in the dark but closes at least two races in the
transition of socket state with respect to socket buffer state.
Yes! This fixes it, on the tag
On Tue, May 24, 2005 at 09:40:20PM +0200, Matthias Buelow wrote:
Bohdan Horst wrote:
I have 4 identical PC with FreeBSD (2x4.11R and 2x5.4R)
Results (/usr/ports/net/benchmarks/nbench):
What you're benchmarking here is gcc3 vs. gcc2.
You could compile nbench on FreeBSD 4.11 with
On Tue, May 17, 2005 at 10:37:37AM -0700, Gary Kline wrote:
Anybody on this geek list know any other societies where the
surname is traditionally presented first and the given name
last?
Geek list ? Ah! That probably means I'm allowed to say Star Trek's
Bajorans suffer from
On Tue, May 17, 2005 at 09:22:33PM +0200, Johan van Selst wrote:
Other variations may appear as well, but are not very common. You may
address me as 'Johan', 'Johan van Selst' or even 'Mr. van Selst' -
but _not_ (never ever) as 'Johan van'. Thank you.
Although 'Mr. van Selst' only applied if
On Tue, May 03, 2005 at 05:00:14PM +0200, Marc Olzheim wrote:
Is this going to be fixed before 5.4 ? It still breaks on today's
5.4-STABLE.
As this is the only issue known to me now, that I don't have a patch
for and is standing in my way of upgrading from FreeBSD 4.x to 5.x, I
would like
On Wed, May 04, 2005 at 02:19:13PM +0200, Gerrit Khn wrote:
Hi folks,
has anyone used the subject successfully with -stable?
umass(4) mentions the 8MB version, so I thought 16MB should actually work,
too. However, when I plug the device in, I just get
ugen0: Trek Technology ThumbDrive,
On Wed, May 04, 2005 at 04:23:51PM +0200, Marc Olzheim wrote:
Any hints how to make this work?
You _do_ have scsi disk support (device da) enabled in your kernel ?
And loaded the umass module or have it in your kernel, for that matter ?
Marc
pgpWpcRUFu55s.pgp
Description: PGP signature
FreeBSD 5.4-STABLE #12: Mon May 2 19:23:22 CEST 2005 [EMAIL
PROTECTED]:/usr/obj/usr/src/sys/HAMMER
hammer:~/src/hak/fpugdb ./fpu5th
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to
On Tue, May 03, 2005 at 04:43:13PM +0200, Marc Olzheim wrote:
FreeBSD 5.4-STABLE #12: Mon May 2 19:23:22 CEST 2005 [EMAIL
PROTECTED]:/usr/obj/usr/src/sys/HAMMER
Doing exactly the same on i386 SMP results in a hanging gdb and the
process exiting with signal 8.
blackmetal:~#ps uaxwlp 759
Is this going to be fixed before 5.4 ? It still breaks on today's
5.4-STABLE.
Marc
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
On Fri, Apr 29, 2005 at 07:28:42PM -0700, Doug White wrote:
The same system about which I just mailed, crashes when booting with
verbose logging enabled. With a normal boot, everything's ok...
Looks like it perturbs some sort of timing and upsets the SCSI card. Is
this on a serail
On Tue, Apr 26, 2005 at 03:36:02PM -0400, Brian Fundakowski Feldman wrote:
I'm still guessing that for whatever reason your writes on the FreeBSD
4.x NFS client are not using NFSv3/transactions. The second method
I just now implemented; it works fine except for being slower since
all data is
FreeBSD 5.4-STABLE #5: Wed Apr 6 15:16:36 CEST 2005
Slab at 0xc866cfa8, freei 0 = 12.
panic: Duplicate free of item 0xc866c000 from zone 0xc103e9a0(Mbuf)
cpuid = 2
KDB: stack backtrace:
kdb_backtrace(100,c569dd80,0,c866cfa8,c56363c0) at 0xc053f121 =
kdb_backtrace+0x29
On Wed, Apr 27, 2005 at 12:08:57PM -0400, Brian Fundakowski Feldman wrote:
Yes, a single writev(). Just like in the kern/79207 PR.
It doesn't have to be superfast (why would I use NFS otherwise), just as
long as it's threadsafe / atomic.
Alright, this will do synchronous, instead of
The same system about which I just mailed, crashes when booting with
verbose logging enabled. With a normal boot, everything's ok...
Marc
KDB: debugger backends: ddb
KDB: current backend: ddb
131072K of memory above 4GB ignored
Copyright (c) 1992-2005 The FreeBSD Project.
Copyright (c) 1979,
On Wed, Apr 27, 2005 at 07:46:28PM +0200, Marc Santhoff wrote:
Hi,
I've updates my system this morning after reading about the usb mfc. The
sources used before are dated from january. I'm not sure if this error
was triggered by the update, but:
Using sysctl -a it seems to lose track after
On Wed, Apr 27, 2005 at 08:24:36PM +0200, Marc Santhoff wrote:
That is 'kern.msgbuf' ;-)
Hm, I've never seen such a verbose output before.
Has anything changed in that area? And why does it still occur after a
reboot, normally buffers are only temporarily valid(at least I thought
so
On Wed, Apr 27, 2005 at 02:34:35PM -0400, Brian Fundakowski Feldman wrote:
Alright, thanks for helping with this :-) Do you think you can find
a way to tell if in 4.x you're actually using NFSv3/transactions? I
would really like to know why 4.x isn't deadlocking, and that's the
most plausible
On Wed, Apr 27, 2005 at 03:06:27PM -0400, Brian Fundakowski Feldman wrote:
How can I tell whether it uses transactions ?
I am not sure -- it should with NFSv3 though. Does mount -v tell
you anything more detailed? I suppose that nfsstat may also be used
-- the commit count should only
On Wed, Apr 27, 2005 at 10:17:46AM +0200, Marc Olzheim wrote:
Btw. running the writev program with 20 * 100 MB on UFS on a 512MB
FreeBSD 6-CURRENT system practicly locks the filesystem down _and_
causes all processes to be swapped out in favor of the buffer cache.
'top' however, doesnt
On Wed, Apr 27, 2005 at 03:41:44PM -0400, Brian Fundakowski Feldman wrote:
Alright, thanks for testing. So the same bug exists in 4.x but may
not actually deadlock the buffer cache in the same circumstances.
If you feel like playing with it anymore, I would expect a certain
write block size,
On Mon, Apr 25, 2005 at 08:06:19PM -0700, Ade Lovett wrote:
SuperMicro [...] Seagate [...]
on-board aic7902
and, from your dmesg output:
da0: SEAGATE ST373207LC 0003 Fixed Direct Access SCSI-3 device
da0: 320.000MB/s transfers [...]
At an absolute minimum, have the existing drive
[changed cc: from standards@ back to stable@ again.]
On Tue, Apr 26, 2005 at 12:25:49PM -0400, Brian Fundakowski Feldman wrote:
You can assure that this happens in only two ways:
1. Make a complete copy of the data. This is what currently occurs:
it gets stuffed into the buffer cache as
On Tue, Apr 12, 2005 at 05:01:43PM +0200, Marc Olzheim wrote:
On Tue, Apr 12, 2005 at 10:40:10AM -0400, Don Bowman wrote:
The problem is with the periodic SMM interrupt and the bios.
The attached program (ich-periodic-smm-disable.c) will fix the problem.
For more information on what
On Mon, Apr 18, 2005 at 10:43:46AM +0200, Claus Guttesen wrote:
Has it even been considered to up these values to something bigger??
Read- and write-size of 32768 seems to work optimal for me:
nfssrv:/nfsmnt /localsrv/nfsmnt nfs
rw,tcp,intr,nfsv3,-w=32768,-r=32768 00
I use
On Tue, Apr 19, 2005 at 09:52:07AM +0200, Emmanuel Chriqui wrote:
Hi,
I'm trying to make very big MD_ROOT (300MB) sent using PXEBOOT+TFTPBOOT. No
NFS.
Any reasons for not using NFS ?
I use i386/5.4RC2/TFTPD/PXEBOOT+TFTPBOOT .
(same pb with a 5.3).
Am I missing something obvious?
On Tue, Apr 19, 2005 at 09:31:10PM +0200, Emmanuel Chriqui wrote:
This is roughly how it works under our linux servers, webservers, etc... I
was hoping to avoid that approach (less work.. less maintenance..).
Am I the only one on earth to need a big MFSROOT ???
:)
Hmm, I guess so. :-P
On Wed, Apr 13, 2005 at 07:06:32PM +0200, Helmut Allwang wrote:
Hello,
it was possible for me, to boot a bootable floppy-image over pxeboot.
Is it possible to boot a CD-image over pxeboot?
You mount the image (mdconfig + mount_cd9660) on your tftp server and
off you go... ;-)
load
On Mon, Apr 11, 2005 at 10:12:32PM -0400, Aaron Summers wrote:
We have a SuperMicro X5DP8-G2 Motherboard, 2xXEON 2.4, 1GB RAM server
running 5.4-STABLE that keeps freezing up. We have replaced RAM, HD,
SCSI controller, etc. To no avail. We are running SMP GENERIC
Kernel. I cannot get the
On Tue, Apr 12, 2005 at 03:06:41PM +0100, Nick Barnes wrote:
The right choice is for mmap() to return ENOMEM, and then for malloc()
to return NULL, but almost no operating systems make this choice any
more.
No, the problem occurs only when previously allocated / mmap()d blocks
are actually
On Tue, Apr 12, 2005 at 10:40:10AM -0400, Don Bowman wrote:
The problem is with the periodic SMM interrupt and the bios.
The attached program (ich-periodic-smm-disable.c) will fix the problem.
For more information on what it does, see the Intel ICH3 datasheet.
compile as 'gcc
Hmm, network services like an ircd, keep functioning until they need to
write a log entry, so it seems that the only thing that's hanging, is
the VFS layer.
Marc
___
freebsd-stable@freebsd.org mailing list
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
FreeBSD 5.3-RELEASE-p6 (SMP) #0: Wed Mar 30 14:28:31 CEST 2005
on i386 is vulnerable as well, so it has been b0rken for some time now,
I'm afraid.
Marc
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (FreeBSD)
On Wed, Mar 30, 2005 at 05:00:31PM +0200, Ulrich Spoerlein wrote:
I really don't know any assembler, but reading
/sys/boot/i386/boot0/boot0.S leads me to believe that there should be a
beep on every boot. However, I certainly don't want any beeps from
boot0, can I comment out the first two
lock order reversal
1st 0xc5d4c900 inp (tcpinp) @ /usr/src/sys/netinet/tcp_usrreq.c:303
2nd 0xc6a0cd10 so_rcv (so_rcv) @ /usr/src/sys/netinet/tcp_usrreq.c:304
3rd 0xc68c1630 inp (tcpinp) @ /usr/src/sys/netinet/in_pcb.c:971
kern.ostype: FreeBSD
kern.osrelease: 5.4-PRERELEASE
kern.osrevision:
On Mon, Mar 14, 2005 at 07:34:21PM +, Bjoern A. Zeeb wrote:
lock order reversal
1st 0xc5d4c900 inp (tcpinp) @ /usr/src/sys/netinet/tcp_usrreq.c:303
2nd 0xc6a0cd10 so_rcv (so_rcv) @ /usr/src/sys/netinet/tcp_usrreq.c:304
3rd 0xc68c1630 inp (tcpinp) @ /usr/src/sys/netinet/in_pcb.c:971
On Tue, Mar 15, 2005 at 12:58:37AM +0100, Marc Olzheim wrote:
Alas, no KDB builtin :-/
Hmmm...:
rave:/# sysctl debug.kdb.available | less
debug.kdb.available: DEC0ADDEDEC0ADDEDEC0ADDE
rave:/#
Is that supposed to happen ?
Marc
pgpu5P0fBvKKJ.pgp
Description: PGP signature
The scheduler is plain SCHED_4BSD btw.
lsof (ports/sysutils) doesn't display anything for pid 20328, but does
for 20326.
The output fstat -vp 20328 generates changes over time; when I try it
now, I get:
turtle:/#fstat -vp 20328
USER CMD PID FD MOUNT INUM MODE
On Sun, Nov 07, 2004 at 04:16:51PM -0800, Dave Hayes wrote:
/kernel: da0 at ahd0 bus 0 target 0 lun 0
/kernel: da0: SEAGATE ST336607LW 0007 Fixed Direct Access SCSI-3 device
/kernel: da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged
Queueing Enabled
/kernel: da0: 35003MB
Hi,
Does anybody know what this is all about ?
http://www.pine.nl/advisories/pine-cert-20020601.html
Zlo
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
I'm running 2.2.6 and this program WREAKED havoc on it :)
It seems to work on NetBSD 1.3.2 too
Perhaps a BSD-ism ?
Marc
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Isn't this a huge problem for ordinary users on a system?? I mean
there aren't any user restrictions on sockets right? I imagine
there will be some sort of follow up on this exploit?
Well, there is a 256k limit per socket of the buffer (I O), try
sysctl kern.maxsockbuf and you can limit
93 matches
Mail list logo
