The kern.timecounter.tick sysctl is apparently intended to return the
kernel variable `tc_tick' but actually returns the kernel variable
`tick'. Returning `tick' is not useful since it is already returned
in the currect place (the kern.clockrate sysctl). Returning `tc_tick'
is apparently not usef
Vladimir Kushnir wrote:
On Mon, 23 Dec 2002, Scott Long wrote:
>Vladimir Kushnir wrote:
>
>
>>I'm not sure for how long but at least last couple of weeks any
attempt to
>>mount CD with UDF gives
>>
>>panic: lockmgr: locking against myself
>>
>>plus quiet reboot (no dump, no break to DDB - not
On Wed, Dec 25, 2002 at 08:57:11AM +1030, Greg 'groggy' Lehey wrote:
> The canonical answer is "you need to build a kernel without the apm
> device". But it's not in GENERIC any more. It's also surprising that
> you haven't seen this problem before: there's nothing specific to 5.0
> about it.
Hr
On Tue, Dec 24, 2002 at 04:39:39PM -0500, Craig Rodrigues wrote:
>
> What motherboard do you have?
>
> This is mine:
> acpi0: on motherboard
acpi0: on motherboard
> Do things work if you add the following line to /etc/sysctl.conf and reboot?
>
> kern.timecounter.hardware=TSC
A. Yes. Tha
* De: Greg 'groggy' Lehey <[EMAIL PROTECTED]> [ Data: 2002-12-24 ]
[ Subjecte: Re: calcru: negative time? ]
> The canonical answer is "you need to build a kernel without the apm
> device". But it's not in GENERIC any more. It's also surprising that
> you haven't seen this problem before:
On Tuesday, 24 December 2002 at 13:37:02 -0800, TwinsPop wrote:
> I'm getting a flurry of these message since upgrading from 4.7-stable to
> 5.0-current (cvsup'd @ 1200PST 12/23):
>
> calcru: negative time of -676146 usec for pid blah blah...
>
> It's an AMD K6-2 system.
>
> http://www.freebsd.or
>
> Hum ... the previous patch against bpf.c was the result of multiple test, thus
> it was _VERY_ ugly with useless lines of code... now the new one is cleaner :)
> (it's just aesthetic modifications but ... better for the eyes :p)
>
> -- Aurelien
@!#~& *tired* here is the ghost patch ... sorr
On Mon, 23 Dec 2002, Scott Long wrote:
> Vladimir Kushnir wrote:
>
> > I'm not sure for how long but at least last couple of weeks any attempt to
> > mount CD with UDF gives
> >
> > panic: lockmgr: locking against myself
> >
> > plus quiet reboot (no dump, no break to DDB - nothing) on my -CURRE
On Tue, Dec 24, 2002 at 09:58:19PM +0100, Aurelien Nephtali wrote:
> Hi,
>
> I think I've found a bug in the BPF stack (if I can call it a stack :p).
> According to the bpf man, packets can be written directly through a bpf file
> descriptor. But writing IP packets using write() doesn't seem to wo
I'm getting a flurry of these message since upgrading from 4.7-stable to
5.0-current (cvsup'd @ 1200PST 12/23):
calcru: negative time of -676146 usec for pid blah blah...
It's an AMD K6-2 system.
http://www.freebsd.org/releases/5.0R/DP1/errata.html
Sent me to the current mailing list. I've ch
Hi,
I think I've found a bug in the BPF stack (if I can call it a stack :p).
According to the bpf man, packets can be written directly through a bpf file
descriptor. But writing IP packets using write() doesn't seem to work, the
"ip_len" field of the ip header isn't sent in host byte order so the
On Tue, Dec 24, 2002 at 12:34:15PM -0700, Geoffrey T. Falk wrote:
> On 24 Dec, Craig Rodrigues wrote:
> > I wrote the attached program to open "/dev/ad0".
> >
> > It consistently fails with:
> > fd: -1
> > Error: : Operation not permitted
>
>
> At what securelevel are you running?
% sysctl -n k
Hi
I have been using version 4.2.1_6 of the VGA X server, specifically the
nv driver. It seems to work reasonably well on 4.7-RELEASE, however it
always crashes on 5.0 RC2. Here's a snippet from the dump info:
(II) NV(0): Initializing int10
(==) NV(0): Write-combining range (0xa,0x2) w
On 24 Dec, Craig Rodrigues wrote:
> I wrote the attached program to open "/dev/ad0".
>
> It consistently fails with:
> fd: -1
> Error: : Operation not permitted
At what securelevel are you running?
g.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the bo
On Tue, Dec 24, 2002 at 10:29:44AM -0800, Yu-Shun Wang wrote:
> Hi,
>
> Can't comment on the reasons for your case, but that number was
> definitely strange. Here's ours:
I figured out what was the problem. On the ia64 box this was
happening we had sio2 interrupting at irq 82, while there was
onl
Hi,
I debugged some more, trying to figure out why I could not
add a new partition to my disk using /usr/sbin/sysinstall
on -CURRENT.
I tracked the problem down to these lines in libdisk's write_i386_disk.c:
98 strcpy(device, _PATH_DEV);
99 strcat(device, d1->name);
Hi,
Can't comment on the reasons for your case, but that number was
definitely strange. Here's ours:
abc% vmstat -i
interrupt total rate
mpt0 irq18 16 0
em0 irq19 380870
On Tue, Dec 24, 2002 at 03:52:05PM +0100, [EMAIL PROTECTED] wrote:
> We can then provide revoke(2) as a wrapper:
>
> revoke(const char *name)
> {
> int fd, e;
>
> fd = open(name, O_RDONLY);
Assuming you can open the thing name points to. I guess it might
b
* De: [EMAIL PROTECTED] [ Data: 2002-12-24 ]
[ Subjecte: Re: revoke(2) redux... ]
> revoke is used in most "login daemons", telnetd, getty and elsewhere.
>
> There is no way you can close the race between:
>
> revoke("/dev/ttyfoo");
> and
> open("/dev/ttyfoo");
>
> Not even i
Hi,
first: Merry Chrismas (or a happy holliday if you don't care about
Christmas).
Yesterday I've updated my -current box and now xdm gets a signal 11 when
I use pam_ssh. My previous world was from Dec. 11.
I don't look more into this issue today, but I've seen changes to ssh
(lastlog issue) and
Hi,
I had UW-Imapd running for the last few weeks on DP2, but after upgrading
to RC2 login fails:
Dec 24 16:37:15 homer kernel: Dec 24 16:37:15 homer imapd[1036]: Login
disabled user=username auth= host= [192.168.0.254]
Dec 24 16:37:18 homer imapd[1036]: Command stream end of file, while
reading
In message <[EMAIL PROTECTED]>, Garrett Wollman
writes:
>< said:
>
>> Isn't there a pretty obvious race between the revoke() and the open() ?
>
>To the extent that the race matters, it is obviated by making sure
>that only the current user has permission to open the device. If the
>user somehow m
< There is no way you can close the race between:
> revoke("/dev/ttyfoo");
> and
> open("/dev/ttyfoo");
> Not even in init(8). There is always the risk that another process
> opens the device between the two.
If that process belongs to root then it doesn't matter.
If that process b
In message <[EMAIL PROTECTED]>, "Paul A. Scott" writes:
>> I think you missed the fine point in the "kick everybody *else*
>> off" comment.
>
>Ahhh. I guess you mean that revoke() would change to do that. You're right,
>I did miss your point.
>
>> The point is you cannot serialize against other pro
< said:
> Isn't there a pretty obvious race between the revoke() and the open() ?
To the extent that the race matters, it is obviated by making sure
that only the current user has permission to open the device. If the
user somehow manages to open a device that he owns anyway, it's his
problem if
> I think you missed the fine point in the "kick everybody *else*
> off" comment.
Ahhh. I guess you mean that revoke() would change to do that. You're right,
I did miss your point.
> The point is you cannot serialize against other processes.
But that's the point of serialization. Anyway, if init
> From: "Paul A. Scott" <[EMAIL PROTECTED]>
> I think what's needed is some form of serialization
> around revoke() and open(). I'm not a master of the init code, but it may be
> that the code is inherently non-reentrant, so the original code would then
> be okay.
Or, it may use spltty()? Or som
In message <[EMAIL PROTECTED]>, "Paul A. Scott" writes:
>
>--
>
>> From: Poul-Henning Kamp <[EMAIL PROTECTED]>
>>>void setctty(char *name) {
>>>(void) revoke(name);
>>>if ((fd = open(name, O_RDWR)) == -1) {
>> Isn't there a pretty obvious race between the revoke() and the open() ?
On Tue, 24 Dec 2002, Poul-Henning Kamp wrote:
> Isn't there a pretty obvious race between the revoke() and the open() ?
>
> Wouldn't it in fact make much more sense if revoke(2) was defined as
>
> int revoke(int fd); /* kick everybody else off */
>
> and the code above would look like:
--
> From: Poul-Henning Kamp <[EMAIL PROTECTED]>
>>void setctty(char *name) {
>>(void) revoke(name);
>>if ((fd = open(name, O_RDWR)) == -1) {
> Isn't there a pretty obvious race between the revoke() and the open() ?
> Wouldn't it in fact make much more sense if revoke(2) was defi
On Tue, Dec 24, 2002 at 12:40:25PM +0100, Poul-Henning Kamp wrote:
> Wouldn't it in fact make much more sense if revoke(2) was defined as
>
> int revoke(int fd); /* kick everybody else off */
>
> and the code above would look like:
An O_REVOKE flag to open might be neater?
Dav
I've been studying revoke(2), and somehow fail to see it fulfill
its promise from the man-page.
Consider this piece of code from init(8):
>/*
> * Start a session and allocate a controlling terminal.
> * Only called by children of init after forking.
> */
>
> Actually only a 4 years -- the a.out->ELF cut over broke the "5-10 years
> of binary compatibility". As mentioned at
> http://gcc.gnu.org/ml/gcc-patches/2002-01/msg01783.html we really made a
> mistake when we did the a.out->ELF cut over thus resulting in us breaking
> the i386 ELF ABI. I have
33 matches
Mail list logo
