Re: kern/163141: process ignore KILL
Synopsis: process ignore KILL State-Changed-From-To: open->closed State-Changed-By: jh State-Changed-When: Fri Dec 9 12:10:33 UTC 2011 State-Changed-Why: You can't get the process killed during nmount(2) system call. When the system call has finished the process can't ignore SIGKILL. This is expected behavior. http://www.freebsd.org/cgi/query-pr.cgi?pr=163141 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs.
The following reply was made to PR kern/163076; it has been noted by GNATS. From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Jaakko Heinonen Cc: Poul-Henning Kamp , Petr Salinger , bug-follo...@freebsd.org, m...@freebsd.org Subject: Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs. Date: Fri, 09 Dec 2011 13:17:59 +0100 Jaakko Heinonen writes: > After looking at some code using sbufs I think that the sbuf(9) API > change done in r222004 is problematic. I agree, but it's far from the first poorly thought-out change in the sbuf API. The biggest mistake was to allow userland to use the same API and code rather than its own implementation of a subset of the API. > Could we just remove the error check from sbuf_len()? (patch below) I > have Cc'd more people. Why? > sbuf(9) manual page wrongly claims that sbuf_data() will return NULL if > the buffer has overflowed. This used to be the case. I don't know why I removed the check. DES --=20 Dag-Erling Sm=C3=B8rgrav - d...@des.no ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: misc/163038: can not connect through ssh to server when /usr is 100% busy
Synopsis: can not connect through ssh to server when /usr is 100% busy State-Changed-From-To: open->closed State-Changed-By: jh State-Changed-When: Fri Dec 9 12:38:52 UTC 2011 State-Changed-Why: Unfortunately not much can be done to fix this. FFS snapshots require suspending all file system operations during the snapshot creation. Snapshot creation can take considerable long time on large file systems. ZFS offers quick snapshotting. http://www.freebsd.org/cgi/query-pr.cgi?pr=163038 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs.
The following reply was made to PR kern/163076; it has been noted by GNATS. From: Jaakko Heinonen To: Dag-Erling =?utf-8?B?U23DuHJncmF2?= Cc: Poul-Henning Kamp , Petr Salinger , bug-follo...@freebsd.org, m...@freebsd.org Subject: Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs. Date: Fri, 9 Dec 2011 14:36:17 +0200 On 2011-12-09, Dag-Erling Smørgrav wrote: > > Could we just remove the error check from sbuf_len()? (patch below) I > > have Cc'd more people. > > Why? As I wrote existing code depends on sbuf_len() to return the actual length regardless of the error status after sbuf_finish(). I am not willing to through all code using sbufs to check where it causes problems. phk@ asserts that r222004 is correct. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs.
The following reply was made to PR kern/163076; it has been noted by GNATS. From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Jaakko Heinonen Cc: Poul-Henning Kamp , Petr Salinger , bug-follo...@freebsd.org, m...@freebsd.org Subject: Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs. Date: Fri, 09 Dec 2011 15:04:22 +0100 Jaakko Heinonen writes: > As I wrote existing code depends on sbuf_len() to return the actual > length regardless of the error status after sbuf_finish(). I am not > willing to through all code using sbufs to check where it causes > problems. phk@ asserts that r222004 is correct. What if the sbuf is in a state where asking for its length is meaningless? DES --=20 Dag-Erling Sm=C3=B8rgrav - d...@des.no ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs.
The following reply was made to PR kern/163076; it has been noted by GNATS. From: Jaakko Heinonen To: Dag-Erling =?utf-8?B?U23DuHJncmF2?= Cc: Poul-Henning Kamp , Petr Salinger , bug-follo...@freebsd.org, m...@freebsd.org Subject: Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs. Date: Fri, 9 Dec 2011 16:35:30 +0200 On 2011-12-09, Dag-Erling Smørgrav wrote: > Jaakko Heinonen writes: > > As I wrote existing code depends on sbuf_len() to return the actual > > length regardless of the error status after sbuf_finish(). I am not > > willing to through all code using sbufs to check where it causes > > problems. phk@ asserts that r222004 is correct. > > What if the sbuf is in a state where asking for its length is > meaningless? Could you give an example about such state? Isn't the length first initialized to zero and then increased only when byte(s) has been successfully appended to the buffer? sbuf_len() has worked for unfinished buffers since r71724. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs.
The following reply was made to PR kern/163076; it has been noted by GNATS. From: "Poul-Henning Kamp" To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= Cc: Jaakko Heinonen , Petr Salinger , bug-follo...@freebsd.org, m...@freebsd.org Subject: Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs. Date: Fri, 09 Dec 2011 14:51:15 + In message <86d3bxaljt@ds4.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wr ites: >Jaakko Heinonen writes: >> As I wrote existing code depends on sbuf_len() to return the actual >> length regardless of the error status after sbuf_finish(). I am not >> willing to through all code using sbufs to check where it causes >> problems. phk@ asserts that r222004 is correct. > >What if the sbuf is in a state where asking for its length is >meaningless? It will always have a length, but the length may not represent all you tried to stuff into the sbuf, if the sbuf has failed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs.
The following reply was made to PR kern/163076; it has been noted by GNATS. From: m...@freebsd.org To: Jaakko Heinonen Cc: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= , Poul-Henning Kamp , Petr Salinger , bug-follo...@freebsd.org Subject: Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs. Date: Fri, 9 Dec 2011 07:33:46 -0800 2011/12/9 Jaakko Heinonen : > On 2011-12-09, Dag-Erling Sm=F8rgrav wrote: >> > Could we just remove the error check from sbuf_len()? (patch below) I >> > have Cc'd more people. >> >> Why? > > As I wrote existing code depends on sbuf_len() to return the actual > length regardless of the error status after sbuf_finish(). I am not > willing to through all code using sbufs to check where it causes > problems. phk@ asserts that r222004 is correct. What is causing sbuf to have an error in the first place? The size of flies in /proc are generally small and malloc(3) errors are rare. Thanks, matthew ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs.
The following reply was made to PR kern/163076; it has been noted by GNATS. From: Petr Salinger To: m...@freebsd.org Cc: Jaakko Heinonen , =?ISO-8859-15?Q?Dag-Erling_Sm=F8rgrav?= , Poul-Henning Kamp , bug-follo...@freebsd.org Subject: Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs. Date: Fri, 9 Dec 2011 17:18:00 +0100 (CET) User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-FELK-MailScanner-Information: X-MailScanner-ID: pB9G4r01051652 X-FELK-MailScanner: Found to be clean X-FELK-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.12, required 6, BAYES_00 -1.90, FREEMAIL_FROM 0.00, SPF_NEUTRAL 0.78) X-FELK-MailScanner-From: petr.salin...@seznam.cz X-FELK-MailScanner-To: bug-follo...@freebsd.org, d...@des.no, j...@freebsd.org, m...@freebsd.org, p...@phk.freebsd.dk X-FELK-MailScanner-Watermark: 1324051494.72495@1Eu3fJUhMt52tBWic+21fw X-Spam-Status: No >> As I wrote existing code depends on sbuf_len() to return the actual >> length regardless of the error status after sbuf_finish(). I am not >> willing to through all code using sbufs to check where it causes >> problems. phk@ asserts that r222004 is correct. > > What is causing sbuf to have an error in the first place? The size of > flies in /proc are generally small and malloc(3) errors are rare. In this particular case, the userland wants to read first n bytes, the sbuf is allocated as fixed for n bytes. The first n bytes are generated and correctly stored in sbuf, for the rest bytes, there is no space in sbuf, but these bytes are not needed later anyway. In stable-8, sbuf_data(sb) point to data, the sbuf_len(sb) returns number of stored bytes. In stable-9, sbuf_data(sb) point to data, the sbuf_len(sb) returns -1. Petr ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs.
The following reply was made to PR kern/163076; it has been noted by GNATS. From: "Poul-Henning Kamp" To: Jaakko Heinonen Cc: Dag-Erling =?utf-8?B?U23DuHJncmF2?= , Petr Salinger , bug-follo...@freebsd.org, m...@freebsd.org Subject: Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs. Date: Fri, 09 Dec 2011 16:08:12 + In message <20111209123616.ga32...@a91-153-116-96.elisa-laajakaista.fi>, Jaakko Heinonen writes: >On 2011-12-09, Dag-Erling Smørgrav wrote: >As I wrote existing code depends on sbuf_len() to return the actual >length regardless of the error status after sbuf_finish(). What do you mean by "actual length" ? The length it would have if there hadn't been errors ? I don't object to that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs.
The following reply was made to PR kern/163076; it has been noted by GNATS. From: Jaakko Heinonen To: Poul-Henning Kamp Cc: Dag-Erling =?utf-8?B?U23DuHJncmF2?= , Petr Salinger , bug-follo...@freebsd.org, m...@freebsd.org Subject: Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs. Date: Fri, 9 Dec 2011 18:23:18 +0200 On 2011-12-09, Poul-Henning Kamp wrote: > >As I wrote existing code depends on sbuf_len() to return the actual > >length regardless of the error status after sbuf_finish(). > > What do you mean by "actual length" ? > > The length it would have if there hadn't been errors ? No, I mean returning s->s_len instead of -1. s_len is the length of the string without the terminating NUL. s_len doesn't include the bytes that didn't fit to the buffer. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/151758: [panic] tmux kernel panic, with out root privilegies
Synopsis: [panic] tmux kernel panic, with out root privilegies State-Changed-From-To: open->patched State-Changed-By: jhb State-Changed-When: Fri Dec 9 17:49:43 UTC 2011 State-Changed-Why: Fix committed to HEAD, will MFC in a few weeks when 9.0 freeze is over. Responsible-Changed-From-To: freebsd-bugs->jhb Responsible-Changed-By: jhb Responsible-Changed-When: Fri Dec 9 17:49:43 UTC 2011 Responsible-Changed-Why: Fix committed to HEAD, will MFC in a few weeks when 9.0 freeze is over. http://www.freebsd.org/cgi/query-pr.cgi?pr=151758 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/163141: process ignore KILL
The following reply was made to PR kern/163141; it has been noted by GNATS. From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= To: bug-follo...@freebsd.org, kes-...@yandex.ru Cc: Subject: Re: kern/163141: process ignore KILL Date: Fri, 9 Dec 2011 21:34:26 +0200 May be that will be usefull to add this info into man mksnap_ffs ? ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/163154: [iwn] fatal firmware error on 9.0-RC3
>Number: 163154
>Category: kern
>Synopsis: [iwn] fatal firmware error on 9.0-RC3
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Fri Dec 09 22:00:28 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Trois Six
>Release:9.0-RC3-amd64
>Organization:
>Environment:
FreeBSD TFR12PERR.telindus.intra 9.0-RC3 FreeBSD 9.0-RC3 #0: Sun Dec 4
08:56:36 UTC 2011 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
amd64
>Description:
My network card : iwn0: mem
0xd330-0xd3301fff irq 19 at device 0.0 on pci68
/etc/rc.conf contains the following:
wlans_iwn0="wlan0"
ifconfig_wlan0="WPA DHCP"
And /etc/wpa_supplicant.conf has the appropriate settings for some access
points :
network={
ssid="myssid"
psk=myasciikey
}
When the system boots or when I start the interface with netif, I have a fatal
firmware error and I can't use my card. I tried to disable the bgscan but it
didn't change anything :
wlan0: Ethernet address: 00:24:d7:XX:XX:XX
iwn0: iwn_intr: fatal firmware error
firmware error log:
error type = "SYSASSERT" (0x0005)
program counter = 0x3C2C
source line = 0x0580
error data = 0x0001
branch link = 0x3C283C28
interrupt link = 0x1532
time= 183809626
driver status:
tx ring 0: qid=0 cur=0 queued=0
tx ring 1: qid=1 cur=0 queued=0
tx ring 2: qid=2 cur=0 queued=0
tx ring 3: qid=3 cur=2 queued=0
tx ring 4: qid=4 cur=64 queued=0
tx ring 5: qid=5 cur=0 queued=0
tx ring 6: qid=6 cur=0 queued=0
tx ring 7: qid=7 cur=0 queued=0
tx ring 8: qid=8 cur=0 queued=0
tx ring 9: qid=9 cur=0 queued=0
tx ring 10: qid=10 cur=0 queued=0
tx ring 11: qid=11 cur=0 queued=0
tx ring 12: qid=12 cur=0 queued=0
tx ring 13: qid=13 cur=0 queued=0
tx ring 14: qid=14 cur=0 queued=0
tx ring 15: qid=15 cur=0 queued=0
tx ring 16: qid=16 cur=0 queued=0
tx ring 17: qid=17 cur=0 queued=0
tx ring 18: qid=18 cur=0 queued=0
tx ring 19: qid=19 cur=0 queued=0
rx ring: cur=14
the link changes from DOWN to UP to DOWN.
I have seen that after every netif start I have two wpa_supplicant process ?
>How-To-Repeat:
At every boot or netif start
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/163155: System halt isnt realy halt
>Number: 163155 >Category: misc >Synopsis: System halt isnt realy halt >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Dec 09 22:20:09 UTC 2011 >Closed-Date: >Last-Modified: >Originator: crow >Release:FreeBSD 9.0 RC3 >Organization: >Environment: FreeBSD alamak 9.0-RC3 FreeBSD 9.0-RC3 #0: Sun Dec 4 08:01:02 UTC 2011 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >Description: Power of laptop (Dell Latitude D630 bios A17) with shutdown -h now, does bring this laptop on half halt state because after the message "The operating system has halted." new line appiers with "Please press any key to reboot." and if I press any key laptop reboots. How is then system halted if it can service the interrupt for the key press to reboot pc. shutdown -p now and poweroff does correctly poweroff this laptop. I am not sure if this can have something with BIOS which isn't aligned with allowing halt from the OS. >How-To-Repeat: Enter the: shutdown -h now >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs.
The following reply was made to PR kern/163076; it has been noted by GNATS. From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Jaakko Heinonen Cc: Poul-Henning Kamp , Petr Salinger , bug-follo...@freebsd.org, m...@freebsd.org Subject: Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs. Date: Sat, 10 Dec 2011 02:13:56 +0100 Jaakko Heinonen writes: > Dag-Erling Sm=C3=B8rgrav wrote: > > What if the sbuf is in a state where asking for its length is > > meaningless? > Could you give an example about such state? Isn't the length first > initialized to zero and then increased only when byte(s) has been > successfully appended to the buffer? sbuf_len() has worked for > unfinished buffers since r71724. A fixed-length sbuf may overflow intentionally (as in pseudofs) or unintentionally; a dynamic sbuf may also overflow due to a memory allocation failure. The first two cases are expected, but the third is not, and I am not sure the sbuf should be considered valid in such a case. DES --=20 Dag-Erling Sm=C3=B8rgrav - d...@des.no ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/147226: [libc] read(fd, buffer, len) returns -1 immediately, if len > =2147483648
The following reply was made to PR kern/147226; it has been noted by GNATS. From: Scott Parrish To: bug-follo...@freebsd.org, eugene.kharito...@gmail.com Cc: Subject: Re: kern/147226: [libc] read(fd, buffer, len) returns -1 immediately, if len >=2147483648 Date: Sat, 10 Dec 2011 00:11:07 -0500 Hi folks, I stumbled across this PR as I was looking at one of the patches for = devel/git (i.e. devel/git/files/patch-wrapper.c) =46rom reading through the PR, it sounds as if the spec isn't entirely = clear. Any ideas where this will land? Thanks, -Scott= ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
