Hello,
Sometimes when I burn data CD's from ISO's at 12x speed like so:
# burncd -f /dev/acd1c -s 12 data file.iso fixate
The fixate fails, and I believe it is because the CD-R has not yet
spun down from the burn phase. The problem doesn't occur when the
burn is done at a lower speed. The fix
íÏÅÊ ÄÏÞÅÒÉ òÉÔÅ 7 ÌÅÔ. 1 ÑÎ×ÁÒÑ 2001 ÇÏÄÁ Õ ÎÅÅ ÎÁÞÁÌÉÓØ ÓÐÁÚÍÙ ÐÏÞËÉ, Á ÎÁ
ÓÌÅÄÕÀÝÉÊ ÄÅÎØ ×ÙÌÉÌÓÑ ÐÏÞÔÉ ÌÉÔÒ ËÒÏ×É. íÁÒÇÁÒÉÔÅ ÐÏÓÔÁ×ÉÌÉ ÓÔÒÁÛÎÙÊ
ÄÉÁÇÎÏÚ - ÏÐÕÈÏÌØ ÷ÉÌÍÓÁ ÐÒÁ×ÏÊ ÐÏÞËÉ Ó ÍÅÔÁÓÔÁÚÁÍÉ × ÐÒÁ×ÏÅ ÌÅÇËÏÅ, 4-Ñ
ÓÔÁÄÉÑ.
ó ÜÔÏÇÏ ÍÏÍÅÎÔÁ ÄÅ×ÏÞËÁ ÐÅÒÅÎÅÓÌÁ ËÕÒÓ ÉÎÔÅÎÓÉ×ÎÏÊ ÌÕÞÅ×ÏÊ É ÈÉÍÉÏÔÅÒ
Hello everyone.
I am looking at some PRs and I am trying to come up with a solution to
submit a patch. I know how to use expr to test as tring in sh inside
of a /etc/rc* script, but what method would people recommend to remove
part of the string after expr confirmed that something is part of it ?
> > 1) scan the sysent table and check syscalls pointers (generally, rootkits
> > intercepts syscalls)
>
> This can get really "hairy". To scan the syscall table, even if you
> are 'root' and directly access /dev/mem you will have to use some
> system calls to open(), read() and seek() into the
Hello,
> > 1) scan the sysent table and check syscalls pointers (generally,
rootkits
> > intercepts syscalls)
>
> This can get really "hairy". To scan the syscall table, even if you
> are 'root' and directly access /dev/mem you will have to use some
> system calls to open(), read() and seek() in
In a message dated 9/9/01 2:52:52 AM Eastern Daylight Time,
[EMAIL PROTECTED] writes:
> : I've encountered a MB that seems to probe devices in a less than
desirable
> : order. There is an onboard fxp controller, but it scans the slots first,
> so
> : that the onboard controller is fxp1 if
In a message dated 9/9/01 12:45:06 PM Eastern Daylight Time, [EMAIL PROTECTED]
writes:
> Also, which routing specifically implements the probe calls to drivers?
> Another option is to probe the wired device first explicitly, and then
skip
>
> it in the normal probe scan. In linux there i
I've actually noticed that the probe order in FreeBSD appears to have
changed between RELENG_4 and -CURRENT. I likewise experienced it with
on-board and external fxp chipsets, only in my case, the probe order for
(fxp0, fxp1) switched with (fxp2, fxp3), as there were two on-MB and two
on a card.
* Ulf Zimmermann <[EMAIL PROTECTED]> [010909 04:47] wrote:
> Hello everyone.
>
> I am looking at some PRs and I am trying to come up with a solution to
> submit a patch. I know how to use expr to test as tring in sh inside
> of a /etc/rc* script, but what method would people recommend to remove
>
On Sun, Sep 09, 2001 at 01:11:52PM -0500, Alfred Perlstein wrote:
> * Ulf Zimmermann <[EMAIL PROTECTED]> [010909 04:47] wrote:
> > Hello everyone.
> >
> > I am looking at some PRs and I am trying to come up with a solution to
> > submit a patch. I know how to use expr to test as tring in sh insid
On Sun 2001-09-09 (13:38), Ulf Zimmermann wrote:
> On Sun, Sep 09, 2001 at 01:11:52PM -0500, Alfred Perlstein wrote:
> > * Ulf Zimmermann <[EMAIL PROTECTED]> [010909 04:47] wrote:
> > > Hello everyone.
> > >
> > > I am looking at some PRs and I am trying to come up with a solution to
> > > submit
On Sun, Sep 09, 2001 at 01:38:00PM -0700, Ulf Zimmermann wrote:
> On Sun, Sep 09, 2001 at 01:11:52PM -0500, Alfred Perlstein wrote:
> > * Ulf Zimmermann <[EMAIL PROTECTED]> [010909 04:47] wrote:
> > > Hello everyone.
> > >
> > > I am looking at some PRs and I am trying to come up with a solution
>
> Also, which routing specifically implements the probe calls to drivers?
device_probe_and_attach
> Another option is to probe the wired device first explicitly, and then skip
> it in the normal probe scan. In linux there is a clearly defined routine
> that does this, but i havent found
On Sun, 9 Sep 2001, Ulf Zimmermann wrote:
> These are some examples strings:
>
> "dhcp"
> "dhcp media 10baseTX"
> "media 10baseTX dhcp mediaopt half-duplex"
>
> The following code will get me inside a if condition:
>
> if [ `expr "${ifconfig_args}" : '.*[Dd][Hh][Cc][Pp].*'` -ne 0 ]; then
>
I want to run an application with the OS set to send small TCP packets
to spot programming errors like assuming that a write of 100 bytes on
a socket can be read in a single read operation. It may work most of
the time but break at some point. So if I could configure FreeBSD to
use small packets
* Kent Boortz <[EMAIL PROTECTED]> [010909 17:49] wrote:
>
> I want to run an application with the OS set to send small TCP packets
> to spot programming errors like assuming that a write of 100 bytes on
> a socket can be read in a single read operation. It may work most of
> the time but break at
In a message dated 9/9/01 5:21:51 PM Eastern Daylight Time,
[EMAIL PROTECTED] writes:
> The entire PCI probe/attach process is going to have to change, however I
> don't see it changing all that much. It is hard to detect devices that
> are "onboard" as opposed to being in physical slots, a
Hi,
Aren't operating systems supposed to use the PCI BIOS calls for finding
devices ? So the scanning order would then be controlled by the BIOS,
and then always follow the intent of the hardware manufacturer ? Or is
there problems with their intent ?
Regards,
Soren
[EMAIL PROTECTED] wrote:
I have just freed up my last 'committed' project, and I've got some spare
cycles to burn.
I've been thinking about how much goes untested in a release, and have been
thinking about how to put together a test harness to check as many things as
possible.
Thats got me thinking (again) about a test
---On Sun, 09 Sep 2001 Farooq Mela <[EMAIL PROTECTED]>
>Subject: Failure to fixate cd in burncd
> ... Any thoughts?
Not knowing what CDR you are using makes your problem difficult to
analyze. Each IDE CDR behaves differently.
Check out Soren Schmidt's page:
http://free
[EMAIL PROTECTED] (Alfred Perlstein) writes:
> there's a setsockopt for this called TCP_NODELAY in netinet/tcp.h.
>
> you should read further into stevens before posting such questions.
I seem to have expressed myself really bad :-( I want to debug an
application. We have had code that broke on
In message <[EMAIL PROTECTED]> Soren Kristensen writes:
: Aren't operating systems supposed to use the PCI BIOS calls for finding
: devices ? So the scanning order would then be controlled by the BIOS,
: and then always follow the intent of the hardware manufacturer ? Or is
: there problems with t
22 matches
Mail list logo
