Greetings,
I've run into a problem with the onboard Broadcom 5704 NetXtreme nics
on a Tyan S2891 Thunder K8SRE motherboard.
Here is the relevant dmesg output to show the error:
pcib5: ACPI PCI-PCI bridge at device 11.0 on pci8
pci10: ACPI PCI bus on pcib5
pcib5: memory: end (de1f) start
On 7/15/07, Tim Kientzle [EMAIL PROTECTED] wrote:
Ulrich Spoerlein wrote:
Simple and elegant. It would also do away with those base.aa, base.ab,
etc. madness.
I'm confused. base.aa, etc, are a tar file, so I don't
entirely understand how this would be different? The
current installer does
Victor Snezhko wrote:
Also, this was a surprise to an unexperienced me, but I have also
found that vfs_mount initializes RTC with the latest timestamp found
on local file systems - this explains why kernel worked for Ivan on
a hard drive. It didn't actually work, but used timestamp which was
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Tim Kientzle wrote:
Paul Schenkeveld wrote:
Having a file describing everything that gets installed would also
benefit
later upgrades to a system.
One of my questions: Does my proposed format suffice for these
other purposes? If not, what
Brian Chu [EMAIL PROTECTED] writes:
Dag-Erling Smørgrav [EMAIL PROTECTED] writes:
Brian Chu [EMAIL PROTECTED] writes:
I have a question about indentation. In the previously supplied
.emacs hook, tabs are represented by 8 spaces.
No, Emacs automatically converts spaces to tabs according
On 2007-Jul-15 16:51:38 -0700, Julian Elischer [EMAIL PROTECTED] wrote:
void
closefrom(int lowfd)
{
fcntl(lowfd, F_CLOSEM, NULL);
}
what on earth would that achieve?
(as opposed to just a simple syscall)
The only benefit I can think of is minimising the number of syscalls.
Is there any
Ivan Voras [EMAIL PROTECTED] writes:
Also, this was a surprise to an unexperienced me, but I have also
found that vfs_mount initializes RTC with the latest timestamp found
on local file systems - this explains why kernel worked for Ivan on
a hard drive. It didn't actually work, but used
Hello again Hackers,
I ran some tests and I noticed a large difference in the cumulative
sums of fwrite(2) vs write(3) and fread(2) vs read(3) (3-fold
differences on a real machine).
Please download
http://students.washington.edu/youshi10/posted/fat.tgz, take a look at
README for some
On Wed, 2007-05-30 at 08:21 +0200, Dag-Erling Smørgrav wrote:
...
Emacs setup (for both C and C++):
(defun des-knf ()
(interactive)
;; Basic indent is 8 spaces
(make-local-variable 'c-basic-offset)
(setq c-basic-offset 8)
;; Continuation lines are indented 4 spaces
On Monday 16 July 2007 01:37:40 am James Shank wrote:
Greetings,
I've run into a problem with the onboard Broadcom 5704 NetXtreme nics
on a Tyan S2891 Thunder K8SRE motherboard.
Here is the relevant dmesg output to show the error:
pcib5: ACPI PCI-PCI bridge at device 11.0 on pci8
On Monday 16 July 2007 04:08:39 am Ivan Voras wrote:
Victor Snezhko wrote:
Also, this was a surprise to an unexperienced me, but I have also
found that vfs_mount initializes RTC with the latest timestamp found
on local file systems - this explains why kernel worked for Ivan on
a hard
John Baldwin wrote:
It's more that we use the filesystem's timestamp as a way to validate the
timestamp from the RTC and to do a fixup if the RTC appears to be dead.
Why not use something that doesn't depend on external factors, like
kernel build time (AFAIK it's embedded somewhere - at least
On Thursday 14 June 2007 03:58:30 am Roman Divacky wrote:
On Thu, Jun 14, 2007 at 09:54:39AM +0200, Roman Divacky wrote:
hi
currently in exit1() we call acct_process() with Giant held.
I looked at the code and I think this is because of tty need
for Giant locking. Because of this we
On Monday 16 July 2007 09:14:04 am Ivan Voras wrote:
John Baldwin wrote:
It's more that we use the filesystem's timestamp as a way to validate the
timestamp from the RTC and to do a fixup if the RTC appears to be dead.
Why not use something that doesn't depend on external factors, like
On Mon, 16 Jul 2007, Tom Evans wrote:
On Wed, 2007-05-30 at 08:21 +0200, Dag-Erling Smørgrav wrote:
...
Emacs setup (for both C and C++):
(defun des-knf ()
(interactive)
;; Basic indent is 8 spaces
(make-local-variable 'c-basic-offset)
(setq c-basic-offset 8)
;; Continuation lines
Being able to record a series of incremental changes in a filesystem
hierarchy, and then roll them back as required. That would be
exceedingly useful, and I think your 'ntree' format has virtually
everything necessary to do that. The most obvious missing bit I can
see is creating a backup of a
Ulrich Spoerlein wrote:
On 7/15/07, Tim Kientzle [EMAIL PROTECTED] wrote:
Plus: The specification file can re-use the existing
files on CD, ...
That is exactly what I was referring to above. And AFAIK DragonflyBSD
does it in a similar way. They simply copy the live CD onto the HDD.
Minus:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Tim Kientzle wrote:
Being able to record a series of incremental changes in a filesystem
hierarchy, and then roll them back as required. That would be
exceedingly useful, and I think your 'ntree' format has virtually
everything necessary to do
Peter Jeremy wrote:
On 2007-Jul-15 16:51:38 -0700, Julian Elischer [EMAIL PROTECTED] wrote:
void
closefrom(int lowfd)
{
fcntl(lowfd, F_CLOSEM, NULL);
}
what on earth would that achieve?
(as opposed to just a simple syscall)
The only benefit I can think of is minimising the number of
Dear Stefan,
Thanks for your help. I've attached the information you requested.
In particular, here are the relevant sections of the dmesg output:
pcib5: ACPI PCI-PCI bridge at device 11.0 on pci8
pcib5: secondary bus 10
pcib5: subordinate bus 10
pcib5: I/O decode
Dear John,
Thanks for the suggestion. I tried the 7.0 livefs snapshot and had
the same results as with the 6.2 release; identical errors on both.
Thanks,
James
On 7/16/07, John Baldwin [EMAIL PROTECTED] wrote:
On Monday 16 July 2007 01:37:40 am James Shank wrote:
Greetings,
I've run into
Stefan,
Another thing that might be helpful: When I last looked at the
motherboard, I remember seeing the chip identified as a BCM 5704 B1.
The BGE driver seems to think it is a B0. I don't know if this is
significant, but I thought the more information I gave, the more you
and the other smart
Go figure it'd cause panics for other people.
I wasn't using zfs at all but it panicked anyhow once (my amd64 VM only,
not my i386 test server, surprisingly). I wish I'd gotten the panic but I
walked away to get a glass of water, and there wasn't a core dump because
the VM shut down
On Monday 16 July 2007 14:06:57 Garrett Cooper wrote:
I ran some tests and I noticed a large difference in the cumulative
sums of fwrite(2) vs write(3) and fread(2) vs read(3) (3-fold
differences on a real machine).
This difference is at least partially explained when looking
at
On Tue, 17 Jul 2007, Heiko Wundram (Beenic) wrote:
On Monday 16 July 2007 14:06:57 Garrett Cooper wrote:
I ran some tests and I noticed a large difference in the cumulative
sums of fwrite(2) vs write(3) and fread(2) vs read(3) (3-fold
differences on a real machine).
This difference is at
On Tuesday 17 July 2007 02:46:07 [EMAIL PROTECTED] wrote:
Yeah, that's what I meant. I was rather tired when I made that post
at 5:30 this morning. Heh. Thank you for the additional info though. That
was brief, but comprehensive :). -Garrett
For more comprehensive info, check the
26 matches
Mail list logo
