In message <[EMAIL PROTECTED]> Matthew Jacob
writes:
: No, badblocks always reads the whole disk- it emits a list of badblocks.
: It's e2fsck that is then used to tell the filesystem that these blocks are
: unavailable.
Ah. Yes. I see now. It would be useful. Before I discovered this I
hacke
On Fri, 29 Dec 2000, Jonathan Graehl wrote:
> What do you mean, you can have multiple outstanding reads like in SCSI?
> I thought the IDE protocol was fundamentally unable to handle the
> concept.
I dunno- check out Soren's work.
>
> I also thought that IDE drives have been transparently rem
> > This is actually more a question of where to store the flag than
> > anything else.
>
> /boot/loader.conf perhaps, but how does the loader know that the previous boot
> failed so that it knows to fall back? This is much harder, as a failed kernel
> boot usually results in a hang or an instan
John Polstra ([EMAIL PROTECTED]) wrote:
> In article <[EMAIL PROTECTED]>,
> Russell L. Carter <[EMAIL PROTECTED]> wrote:
> >
> > On a fairly recent -STABLE I am getting this failure:
> >
> > ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/rtld.c:2033
> >
> > I assume I'm doing something s
What do you mean, you can have multiple outstanding reads like in SCSI?
I thought the IDE protocol was fundamentally unable to handle the
concept.
I also thought that IDE drives have been transparently remapping bad
blocks (and failing only when they run out of spares) for quite a few
years now.
While trying to get the linux mke2fs to create linux filesystems on
slices,
I have come across a problem with one of the disk ioctls. I am having
trouble tracking it down further, but I think I am close.
After creating a partition table, I am attempting to execute:
mke2fs /dev/ad0s1
So
In article <[EMAIL PROTECTED]>,
Russell L. Carter <[EMAIL PROTECTED]> wrote:
>
> On a fairly recent -STABLE I am getting this failure:
>
> ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/rtld.c:2033
>
> I assume I'm doing something stupid, however the same code
> works on Linux gcc-2.95.2
Title: Æóðíàë "Íîâûé Àêðîïîëü"
Äîðîãèå äðóçüÿ!
Ðåäàêöèÿ æóðíàëà "Íîâûé Àêðîïîëü" îò âñåé äóøè ïîçäðàâëÿåò âàñ ñ Íîâûì ãîäîì è íàñòóïëåíèåì íîâîãî òûñÿ÷åëåòèÿ!
Ïðåäñòàâëÿåì Âàì æóðíàë "Íîâûé Àêðîïîëü". Êîíå÷íî, ó Âàñ âîçíèêíóò âîïðîñû: "À ÷òî ýòî çà æóðíàë? ×åì îí îòëè÷àåòñÿ îò äðó
On Fri, 29 Dec 2000, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Matthew Jacob
>writes:
> : Isn't this what the Linux badblocks program is for? Why don't you take that
> : and find a way to feed this into badsect(8)...
>
> I thought the linux badblocks program found bad blocks and keep
Alexey Dokuchaev wrote:
>
> Hello!
>
> Some pretty good time ago, I accidentally found SecureBSD
> (www.securebsd.org), which is a security patch for 3.4-REL and 4.0-REL. I
> kept a note about this site, and that's about it.
>
> Recently, reviewing my ~/cool.lynx file, I've found this site aga
In message <[EMAIL PROTECTED]> Matthew Jacob
writes:
: Isn't this what the Linux badblocks program is for? Why don't you take that
: and find a way to feed this into badsect(8)...
I thought the linux badblocks program found bad blocks and keep the
user from using them. I want to read the entire
Isn't this what the Linux badblocks program is for? Why don't you take that
and find a way to feed this into badsect(8)...
> OK. I have a disk drive that is failing in random ways. Today blocks
> 123 456 and 293 might be unreadable. Tomorrow, it might be these and
> 27 or it might just be 27
OK. I have a disk drive that is failing in random ways. Today blocks
123 456 and 293 might be unreadable. Tomorrow, it might be these and
27 or it might just be 27. It is an IDE drive. I was wondering if anybody
had a program that would read the entire disk and keep a list/bitmap of
the bad b
Greetings,
On a fairly recent -STABLE I am getting this failure:
ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/rtld.c:2033
I assume I'm doing something stupid, however the same code
works on Linux gcc-2.95.2, so I'm looking for what the
difference might be.
The program is an ACE/TAO C
On 28-Dec-00 Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, "Walter W.
> Ho
> p" writes:
>>Hi all,
>>
>>I was wondering how to increase the robustness of the booting process,
>>so that a box would be able to keep itself on its feet without
>>intervention of the console. I think this w
Title: Æóðíàë "Íîâûé Àêðîïîëü"
Äîðîãèå äðóçüÿ!
Ðåäàêöèÿ æóðíàëà "Íîâûé Àêðîïîëü" îò âñåé äóøè ïîçäðàâëÿåò âàñ ñ Íîâûì ãîäîì è íàñòóïëåíèåì íîâîãî òûñÿ÷åëåòèÿ!
Ïðåäñòàâëÿåì Âàì æóðíàë "Íîâûé Àêðîïîëü". Êîíå÷íî, ó Âàñ âîçíèêíóò âîïðîñû: "À ÷òî ýòî çà æóðíàë? ×åì îí îòëè÷àåòñÿ îò äðó
Dennis wrote:
> >: Still, I personally believe, that "core" or general "freebsd community"
> >: should explicitly state, that support for binary drivers and support
for
> >: easier inclusion of binary driver or just third party driver is eagerly
> >: encouraged. And as much as possible, easy inclu
In message <[EMAIL PROTECTED]> Wes Peters writes:
: What's a good price point for a bedroom/kitchen "thin" computer with an
: 800x600 LCD panel?
If it had builtin ethernet, then I'd go up to $400-$500. If not, then
I'd go $50-$100 less. Especially if there were no slots at all in it.
Warner
In message <[EMAIL PROTECTED]> Dennis writes:
: 4.1 broke that "policy" rather badly. Perhaps its time to get rid of the
: mbuf macros, as any change to that structure breaks binary compatibility in
: the worst way possible.
Agreed. There are too many things that have been MFC'd that change
th
> I work for a commercial company, and I did what I could to convince
> people that *BSD is the way, and we're happily using FreeBSD.
> now, we modiy the kernel sources, and this is a problem since this changes
> the way people build the kernel.
> what we did is provide procedures to modify the ke
Nicolas Souchu writes:
> > If I beat on lm.c from
> > http://www.planet.sci.kobe-u.ac.jp/~takawata/smbus/examples/lm.c
> > enough and use 0x90 as cmd.slave, I can get the CPU temp of 41 C.
> > This is the same as firmware gives me, which is encouraging.
> >
> > As you can probably tell, I
Hello,
> Some pretty good time ago, I accidentally found SecureBSD
> (www.securebsd.org), which is a security patch for 3.4-REL and 4.0-REL. I
> kept a note about this site, and that's about it.
you may also try TrustedBSD: http://www.trustedbsd.org/
Bjoern
--
-BEGIN GEEK CODE BLOCK---
>: Still, I personally believe, that "core" or general "freebsd community"
>: should explicitly state, that support for binary drivers and support for
>: easier inclusion of binary driver or just third party driver is eagerly
>: encouraged. And as much as possible, easy inclusion of binary driver
Bill Fumerola wrote:
>
> On Wed, Dec 27, 2000 at 04:04:36PM -0800, [EMAIL PROTECTED] wrote:
>
> > Bill Fumerola, who states that security policy
> > information is un-available. However, I might
> > refer his comment to the Security Officer instead,
> > if Bill feels this
Warner Losh wrote:
>
> In message <[EMAIL PROTECTED]> Wes Peters writes:
> : We have several NIC's around here (the New Internet Computer, see
> : http://www.thinknic.com/ for details) and will be adding a couple of these
> : so we can boot FreeBSD or NetBSD on them in the next little while. A N
Hello!
Some pretty good time ago, I accidentally found SecureBSD
(www.securebsd.org), which is a security patch for 3.4-REL and 4.0-REL. I
kept a note about this site, and that's about it.
Recently, reviewing my ~/cool.lynx file, I've found this site again.
Interested, I dloaded it (4.0 version
Hi again all,
Well, despite the reception I'm still here, desperately trying to allocate
an I/O port range! Still can't get bus_alloc_resource to work, despite
doing everything by the book. I have a question. My kernel prints this:
amdpm0: at device 7.3 on pci0
...before amdpm_attach complain
> Grab the linux lm_sensor documentation and see if these I2C addresses
> are listed and which chips they are potentially assigned to. At this
> point, it is not SMBus dependent, but chip/vendor dependent.
FWIW, Ralf Brown's interrupt list contains a fairly extensive set of I2C
address assignmen
On Thu, Dec 28, 2000 at 02:57:33PM -0500, Andrew Gallatin wrote:
>
> Nicolas Souchu writes:
> > Gasp! This is part of my fault. I shouldn't have left this old style
> > driver in the tree :( You should have contacted me, I would have adviced
> > you.
> >
> > Takanori is right, you should lo
29 matches
Mail list logo
