Greg 'groggy' Lehey wrote:
On Tuesday, 5 August 2003 at 22:21:41 +0200, Rob wrote:
Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Rob writes:
Hi all,
After cvs'upping (about 12 hours ago) and building world/kernel vinum
stopped working. It does show my two disks but nothing more. I
Hi all,
After cvs'upping (about 12 hours ago) and building world/kernel vinum
stopped working. It does show my two disks but nothing more. I also
get an error message right after the bootloader:
msgbuf cksum mismatch (read a5886, calc a5efb)
On Tuesday, 5 August 2003 at 22:21:41 +0200, Rob wrote:
Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Rob writes:
Hi all,
After cvs'upping (about 12 hours ago) and building world/kernel vinum
stopped working. It does show my two disks but nothing more. I also
get an error message
Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Rob writes:
Hi all,
After cvs'upping (about 12 hours ago) and building world/kernel vinum
stopped working. It does show my two disks but nothing more. I also
get an error message right after the bootloader:
Can you try this patch:
On Friday, 8 August 2003 at 16:04:05 +0200, Rob wrote:
Greg 'groggy' Lehey wrote:
On Tuesday, 5 August 2003 at 22:21:41 +0200, Rob wrote:
Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Rob writes:
Hi all,
After cvs'upping (about 12 hours ago) and building world/kernel vinum
In message [EMAIL PROTECTED], Rob writes:
Hi all,
After cvs'upping (about 12 hours ago) and building world/kernel vinum
stopped working. It does show my two disks but nothing more. I also
get an error message right after the bootloader:
Can you try this patch:
Index: spec_vnops.c
Bernd,
This sounds very promising, but I want to make sure I do this correctly.
When you say to remove the plexes, that means to use 'vinum rm' with
appropriate options, correct? As far as reconfiguring, can I use the
output from 'vinum printconfig' as the input configuration file?
On Mon, Apr 15, 2002 at 04:08:43PM -0500, Patrick Hartling wrote:
Bernd,
This sounds very promising, but I want to make sure I do this
correctly. When you say to remove the plexes, that means to use 'vinum rm'
with appropriate options, correct? As far as reconfiguring, can I
On Fri, Apr 12, 2002 at 05:46:29PM -0500, Patrick Hartling wrote:
I suffered a system crash earlier today running -current from April 10.
I have a Vinum volume set up as a mirror, and during the reboot, I had
to fsck it. Everything seemed normal (at least that's what I thought),
but now
I suffered a system crash earlier today running -current from April 10.
I have a Vinum volume set up as a mirror, and during the reboot, I had
to fsck it. Everything seemed normal (at least that's what I thought),
but now my volume cannot be mounted. The output from 'vinum list' is as
Julian Elischer wrote:
If it is to be counted as my only achivement on -core that I timed
out SLICE and DEVFS, I'll still be proud of what I did there.
Well you timed them out without askling the developer what he had in the
wings and that was more than impolite, it was stupid, because
In message [EMAIL PROTECTED], Ju
lian Elischer writes:
Well you timed them out without askling the developer what he had in the
wings and that was more than impolite, it was stupid, because most of the
shortcomings of devfs and SLICE had been solved and all I was waiting for
was the CAM
[Format recovered--see http://www.lemis.com/email/email-format.html]
Your MUA wraps incorrectly.
On Friday, 17 August 2001 at 9:16:59 +0200, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Julian
Elischer writes:
Well you timed them out without askling the developer what he had in
Poul-Henning Kamp wrote:
Julian Elischer writes:
Well you timed them out without askling the developer what he had in the
wings and that was more than impolite, it was stupid, because most of the
shortcomings of devfs and SLICE had been solved and all I was waiting for
was the CAM
On Fri, 17 Aug 2001, Terry Lambert wrote:
Poul-Henning Kamp wrote:
Julian Elischer writes:
Well you timed them out without askling the developer what he had in the
wings and that was more than impolite, it was stupid, because most of the
shortcomings of devfs and SLICE had been
In message [EMAIL PROTECTED], Ju
lian Elischer writes:
On Fri, 17 Aug 2001, Terry Lambert wrote:
Poul-Henning Kamp wrote:
Julian Elischer writes:
Well you timed them out without askling the developer what he had in the
wings and that was more than impolite, it was stupid, because
On Thursday, 16 August 2001 at 6:36:45 +0200, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Greg Lehey writes:
On Wednesday, 15 August 2001 at 19:17:47 +0200, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Ju
lian Elischer writes:
the lack of subdirectory support is a
In message [EMAIL PROTECTED], Greg Lehey writes:
ls -la /dev/fd
What am I supposed to see there? I get three character devices, all
mounted on /dev directly.
Uhm, have you forgotten how ls(1) works ?
No.
Try this then:
ls -lad /dev/fd /dev/fd/[012]
Hmm. Strange. Last time
On Thu, 16 Aug 2001, Greg Lehey wrote:
On Thursday, 16 August 2001 at 6:36:45 +0200, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Greg Lehey writes:
In view of the fact that this thread is about deficiencies in your
devfs, this is particularly uncalled for. One of the reasons
On Thu, 16 Aug 2001, Poul-Henning Kamp wrote:
After 3 years I gave up on the hope that it would ever be fixed
well enough to become politically acceptable.
After 6 years I removed it.
A quick script run on the cvs tree paints this picture of number
of commits to src/sys/miscfs/devfs
In message [EMAIL PROTECTED], Ju
lian Elischer writes:
A quick script run on the cvs tree paints this picture of number
of commits to src/sys/miscfs/devfs per year:
julian phk other
199556 3 15
199620
[cc's trimmed]
John,
Thanks for the suggestion, I appreciate it. I did as you suggested
(diff below).
It paniced again, but this time savecore said dump time is unreasonable.
The short panic message was:
panicstr: bremfree: bp 0xcc2a1ae4 not locked
Looks like the same thing to me, sorry.
On 16-Aug-01 Michael Lucas wrote:
[cc's trimmed]
John,
Thanks for the suggestion, I appreciate it. I did as you suggested
(diff below).
It paniced again, but this time savecore said dump time is unreasonable.
The short panic message was:
panicstr: bremfree: bp 0xcc2a1ae4 not
On Thu, 16 Aug 2001, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Ju
lian Elischer writes:
A quick script run on the cvs tree paints this picture of number
of commits to src/sys/miscfs/devfs per year:
julian phk other
199556
On Thu, 16 Aug 2001, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Ju
lian Elischer writes:
A quick script run on the cvs tree paints this picture of number
of commits to src/sys/miscfs/devfs per year:
julian phk other
199556
On Thu, 16 Aug 2001, Poul-Henning Kamp wrote:
Julian feels he has no avenue of recourse and gives up..--
if (!strcmp(DEVFS, SLICE))
return (ECONFUSED);
Julian, you had four years, during which you didn't even manage to
make half of the commits made to the DEVFS code
+---[ Poul-Henning Kamp ]--
| In message [EMAIL PROTECTED], Andrew Kenneth Milton
| writes:
| +---[ Greg Lehey ]--
| |
|
| [snip]
|
| | whether it's been fixed. Basically, devfs as supplied in CURRENT had
| | a 16 character limit on device
In message [EMAIL PROTECTED], Andrew Kenneth Milton
writes:
The problem turns up most violently within the XFree86 DRI Module, since
it now uses make_dev, and not mknod as it used to.
The DRI Module first attempts to mkdir /dev/dri/, and then for each card
it supports attempts to use
+---[ Poul-Henning Kamp ]--
| In message [EMAIL PROTECTED], Andrew Kenneth Milton
| writes:
|
| The problem turns up most violently within the XFree86 DRI Module, since
| it now uses make_dev, and not mknod as it used to.
|
| The DRI Module first attempts to mkdir
In message [EMAIL PROTECTED], Andrew Kenneth Milton
writes:
+---[ Poul-Henning Kamp ]--
| In message [EMAIL PROTECTED], Andrew Kenneth Milton
| writes:
|
| The problem turns up most violently within the XFree86 DRI Module, since
| it now uses make_dev, and not mknod as
On Wed, Aug 15, 2001 at 10:21:39AM +0930, Greg Lehey wrote:
On Tuesday, 14 August 2001 at 19:26:09 -0400, Michael Lucas wrote:
Before I start generating crash dumps etc., are there any gotchas
with Vinum -current? I'm using devfs on a SMP system, upgraded 3
days ago. I get a panic
+---[ Poul-Henning Kamp ]--
| In message [EMAIL PROTECTED], Andrew Kenneth Milton
| writes:
| +---[ Poul-Henning Kamp ]--
| | In message [EMAIL PROTECTED], Andrew Kenneth Milton
| | writes:
| |
| | The problem turns up most violently within the
the lack of subdirectory support is a pitty.
it was a primary design goal in the previous devfs and its
disappearance caught me by surprise. (the support I mean)
On Wed, 15 Aug 2001, Andrew Kenneth Milton wrote:
+---[ Poul-Henning Kamp ]--
| In message [EMAIL
In message [EMAIL PROTECTED], Ju
lian Elischer writes:
the lack of subdirectory support is a pitty.
There is support for subdirectories:
ls -la /dev/fd
it was a primary design goal in the previous devfs and its
disappearance caught me by surprise. (the support I mean)
SATIRE
The
On Wed, Aug 15, 2001 at 10:21:39AM +0930, Greg Lehey wrote:
To help localize this problem, could you please try this same thing on
a kernel without devfs? The dump you sent me did not look like a
Vinum bug, as I said in my reply.
Sorry, it happens on a non-devfs kernel as well. Since it
On 15-Aug-01 Michael Lucas wrote:
On Wed, Aug 15, 2001 at 10:21:39AM +0930, Greg Lehey wrote:
To help localize this problem, could you please try this same thing on
a kernel without devfs? The dump you sent me did not look like a
Vinum bug, as I said in my reply.
Sorry, it happens on a
On Wednesday, 15 August 2001 at 19:17:47 +0200, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Ju
lian Elischer writes:
the lack of subdirectory support is a pitty.
There is support for subdirectories:
ls -la /dev/fd
What am I supposed to see there? I get three character
[snip]
And in general, can we stop the high incidence of mud-slinging we've
seen on the lists lately?
Here, here!
Brandon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
In message [EMAIL PROTECTED], Greg Lehey writes:
On Wednesday, 15 August 2001 at 19:17:47 +0200, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Ju
lian Elischer writes:
the lack of subdirectory support is a pitty.
There is support for subdirectories:
ls -la /dev/fd
What am I
Before I start generating crash dumps etc., are there any gotchas
with Vinum -current? I'm using devfs on a SMP system, upgraded 3
days ago. I get a panic whenever I stripe something.
Thanks,
Michael
--
Michael Lucas
[EMAIL PROTECTED]
http://www.blackhelicopters.org/~mwlucas/
Big Scary
On Tuesday, 14 August 2001 at 19:26:09 -0400, Michael Lucas wrote:
Before I start generating crash dumps etc., are there any gotchas
with Vinum -current? I'm using devfs on a SMP system, upgraded 3
days ago. I get a panic whenever I stripe something.
Ah, now you say devfs. There was a
+---[ Greg Lehey ]--
|
[snip]
| whether it's been fixed. Basically, devfs as supplied in CURRENT had
| a 16 character limit on device names, and it didn't understand
| subdirectories: it treated the / as a part of the device name.
The subdir part bit me about a week
In message [EMAIL PROTECTED], Andrew Kenneth Milton
writes:
+---[ Greg Lehey ]--
|
[snip]
| whether it's been fixed. Basically, devfs as supplied in CURRENT had
| a 16 character limit on device names, and it didn't understand
| subdirectories: it treated the / as a
On Wednesday, 15 August 2001 at 7:16:02 +0200, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Andrew Kenneth Milton
writes:
+---[ Greg Lehey ]--
[snip]
whether it's been fixed. Basically, devfs as supplied in CURRENT had
a 16 character limit on device
In message [EMAIL PROTECTED], Greg Lehey writes:
I'm working on the 16char limit problem as well, but I want to avoid
allocating memory in incovenient circumstances if at all possible.
The problem is that I kept having problems with the devfs/vinum
combination even after increasing the size
:The thing is i'm not sure if it's vinum, I could also duplicate this on
:another machine without vinum.. except I duplicated it differently..
:
:Consider the following perl script:
:
:#!/usr/bin/perl
:for ( ; ; ) {
:system("fetch http://www.web.site/index.html");
:}
:
:Of course,
::Jason DiCioccio
Another possibility -- could you post your 'dmesg' output? One thing
that NFS does do is severely exercise both the network and the SCSI
device in a concurrent fashion.
If you happen to be using an NCR SCSI chipset, that could be the cause
of the problem
Here is my dmesg output, and btw, sorry.. the perl script was not running
on the NFS volume, just regularly on a regular 4.0 box, and it crashed the
box (yes, I had login limits set), I was just giving another example of
what seems to be some instability in 4.0 under high loads..
Here my dmesg
One more thing, here's my kernel config file just in case you need it:
machine i386
cpu I586_CPU
ident RAID
maxusers64
makeoptions DEBUG=-g#Build kernel with gdb(1) debug
options DDB_UNATTENDED
options INET
panic: lockmgr: pid -2, exclusive lock holder 5 unlocking
Syncing disks... Timedout SCB handled by another timeout
Timedout handled by another timeout
That is what I get when doing a 'du -k' on an NFS mount from a remote
machine.. THe machine I am speaking of is the actual nfs server, i'm
On Mar 15, Mathew Kanner wrote:
On Mar 15, Greg Lehey wrote:
attention yet, but I do see that your problem relates to soft
updates. It's not clear that the soft updates themselves are a cause
of the problem, or just a facilitator, but it would be interesting to
I did try it couple
Ok, this is NOT a softupdates *or* a vinum problem.
This is a buffer cache problem.
The problem is due to the large block size you are using when newfs'ing
the filesystem coupled with problems in geteblk() which causes severe
buffer cache KVM fragmentation. Softupdates
Oh, addendum... I didn't see this email regarding an actual panic.
There are two problems here, one of which (the nbufkv lockup) should
be solved by my previous email.
The second problem is this panic you are reporting, and I have no idea
what is causing it so this issue
On Mar 23, Matthew Dillon wrote:
Oh, addendum... I didn't see this email regarding an actual panic.
There are two problems here, one of which (the nbufkv lockup) should
be solved by my previous email.
The second problem is this panic you are reporting, and I have no idea
On Wednesday, 15 March 2000 at 16:29:03 -0500, Mathew Kanner wrote:
On Mar 15, Mathew Kanner wrote:
On Mar 15, Soren Schmidt wrote:
Btw are you running the latest 4.0 or -current code ? there was
a time when we had problems with the HPT and Promise controllers ?
The kernel in question
On Mar 15, Soren Schmidt wrote:
It seems Mathew Kanner wrote:
disks on Promise controllers. I believe that the problems lies with
multiple cards on the same interupt but what do I know -- execpt that
the problem goes away when I disable most devices in the BIOS.
The motherboard is
It seems Mathew Kanner wrote:
Hi All,
I wanted to document my difficuties with Vinum and multiple
disks on Promise controllers. I believe that the problems lies with
multiple cards on the same interupt but what do I know -- execpt that
the problem goes away when I disable most
On Mar 15, Mathew Kanner wrote:
On Mar 15, Soren Schmidt wrote:
Btw are you running the latest 4.0 or -current code ? there was
a time when we had problems with the HPT and Promise controllers ?
The kernel in question was cvsup'ed right at the change. I'm
going to try 4.0 today.
On Mar 15, Greg Lehey wrote:
Replying to myself. By now this is probably the wrong list.
I'm not sure what to do anymore. I've tried to set the bios
settings back to what I've had when it worked it it doesn't seem to
want to go. I've set the drives for ata/66 and ata/33. I've
Hi All,
I wanted to document my difficuties with Vinum and multiple
disks on Promise controllers. I believe that the problems lies with
multiple cards on the same interupt but what do I know -- execpt that
the problem goes away when I disable most devices in the BIOS.
60 matches
Mail list logo
