Re: USB removal kernel panic
ср, 15 янв. 2020 г. в 22:15, Martin Pieuchot : > > On 15/01/20(Wed) 20:26, Vadim Zhukov wrote: > > I have a diff or two for that, will send when I'll come home. > > After discussing the issue with Peter Stuge, we figured out that > the free should happen *after* calling config_detach() for the child > device (video(4)). > > When video(4) is detached it will call: > > vdevgone()->videoclose()->uvideo_close() > > this last function will sleep until all I/O are finished or cancelled as > part of usbd_pipe_close(9). > > Diff below should fix the issue. Looks good; works here on amd64 with 2 different uvideo(4) devices, including broken one. > Index: dev/video.c > === > RCS file: /cvs/src/sys/dev/video.c,v > retrieving revision 1.42 > diff -u -p -r1.42 video.c > --- dev/video.c 6 Oct 2019 17:13:10 - 1.42 > +++ dev/video.c 15 Jan 2020 19:11:20 - > @@ -463,9 +463,6 @@ videodetach(struct device *self, int fla > struct video_softc *sc = (struct video_softc *)self; > int maj, mn; > > - if (sc->sc_fbuffer != NULL) > - free(sc->sc_fbuffer, M_DEVBUF, sc->sc_fbufferlen); > - > /* locate the major number */ > for (maj = 0; maj < nchrdev; maj++) > if (cdevsw[maj].d_open == videoopen) > @@ -474,6 +471,8 @@ videodetach(struct device *self, int fla > /* Nuke the vnodes for any open instances (calls close). */ > mn = self->dv_unit; > vdevgone(maj, mn, mn, VCHR); > + > + free(sc->sc_fbuffer, M_DEVBUF, sc->sc_fbufferlen); > > return (0); > } > Index: dev/usb/uvideo.c > === > RCS file: /cvs/src/sys/dev/usb/uvideo.c,v > retrieving revision 1.205 > diff -u -p -r1.205 uvideo.c > --- dev/usb/uvideo.c14 Oct 2019 09:20:48 - 1.205 > +++ dev/usb/uvideo.c15 Jan 2020 19:09:48 - > @@ -644,10 +644,10 @@ uvideo_detach(struct device *self, int f > /* Wait for outstanding requests to complete */ > usbd_delay_ms(sc->sc_udev, UVIDEO_NFRAMES_MAX); > > - uvideo_vs_free_frame(sc); > - > if (sc->sc_videodev != NULL) > rv = config_detach(sc->sc_videodev, flags); > + > + uvideo_vs_free_frame(sc); > > return (rv); > } -- WBR, Vadim Zhukov
Re: USB removal kernel panic
I have a diff or two for that, will send when I'll come home.
ср, 15 янв. 2020 г., 19:28 Martin Pieuchot :
> Thanks for the report.
>
> > ddb{0}>
> memcpy(80165000,fd804da1f728,8d8,80165000,b5bd47118
> > ed5c95a,80165000) at memcpy+0x15
> > uvideo_vs_cb(fd80778f2870,801667d8,0) at uvideo_vs_cb+0x8b
> > usb_transfer_complete(fd80778f2870) at usb_transfer_complete+0x20f
> > xhci_event_dequeue(800af000) at xhci_event_dequeue+0x103
> > xhci_softintr(800af000) at xhci_softintr+0x2d
> > softintr_dispatch(1) at softintr_dispatch+0xf2
> > Xsoftnet(0,819c05e0,0,18041969,80,a) at Xsoftnet+0x1f
> > Xspllower(0,0,c7ef80837208d4cc,8159c000,81983ee1,708000)
> at Xsp
> > llower+0x19
> > free(8159c000,2,708000) at free+0x160
> > uvideo_detach(80165000,1) at uvideo_detach+0x71
> > config_detach(80165000,1) at config_detach+0x152
> > usbd_detach(80137500,80086d00) at usbd_detach+0x5a
> > uhub_port_connect(80086d00,4,2a0,286) at uhub_port_connect+0x68
> > uhub_explore(800a9500) at uhub_explore+0x23d
> > usb_explore(800a9400) at usb_explore+0x12b
> > usb_task_thread(80001f8efb30) at usb_task_thread+0x10b
> > end trace frame: 0x0, count: -16
> > ddb{0}>
> memcpy(80165000,fd804da1f728,8d8,80165000,b5bd47118
>
> It seems that the pipe aren't close when uvideo_detach() is called.
> This is similar to the recent race fixed in uhidev(4). It would be
> great to find a generic way of handling this situation.
>
> uhidev_detach() calls vdevgone() for example...
>
>
Re: fread() on unbuffered FILE doesn't set feof flag
ср, 12 дек. 2018 г. в 10:59, Sebastien Marie : > > On Tue, Dec 11, 2018 at 03:08:38PM -0700, Todd C. Miller wrote: > > On Tue, 11 Dec 2018 20:35:05 +0100, Sebastien Marie wrote: > > > > > According to stdio.h, 6 = __SNBF | __SRD, so "unbuffered" and "OK to > > > read". > > > > > > the feof() call returns false, the python code interpretes it as an error. > > > > > > When looking at fread(3) code in libc, I found that we doesn't set > > > __SEOF when the FILE is unbuffered. > > > > Yes, that is a bug. The code should probably be calling __srefill(), > > though we'd need to set _bf._base and _bf._size appropriately so > > it doesn't use _nbuf. Some care is required... > > > > - todd > > It seems it is the rediscover of a previously signaled bug by zhuk@ . > see https://marc.info/?l=openbsd-tech=152554758706248=2 > > I found it after setting up a patch, and it is mostly the same than the > proposed one by zhuk@, so I take his diff (exactly, only the chunk that > correct the bug. his diff also corrects something else, but I prefer to > take care to only one thing a time). > > The approch is to directly set __SEOF or __SERR. It is more simple than > trying to reuse __srefill(). > > Index: stdio/fread.c > === > RCS file: /cvs/src/lib/libc/stdio/fread.c,v > retrieving revision 1.15 > diff -u -p -r1.15 fread.c > --- stdio/fread.c 21 Sep 2016 04:38:56 - 1.15 > +++ stdio/fread.c 12 Dec 2018 07:52:02 - > @@ -79,6 +79,10 @@ fread(void *buf, size_t size, size_t cou > p += r; > resid -= r; > } > + if (r == 0) > + fp->_flags |= __SEOF; > + else if (r < 0) > + fp->_flags |= __SERR; > FUNLOCKFILE(fp); > return ((total - resid) / size); > } > > I tested it with mercurial, and it corrects the problem. > > Thanks. I've been running libc with this patch for months, and got not problems yet, FWIW. The four lines you're adding are similar to other stdio code, e.g., see vfprintf.c. The hunk you omitted probably not needed in my case (buffered stdio over IPv4 TCP socket), but it seemed to be logical one (EAGAIN received shouldn't invalidate stream offset, it's still well-known), and also seem to be more non-seekable-file-descriptor-friendly. And, again, I've been running both hunks all that time. I'm glad this issue finally got discussed - thanks, I always suck at attracting attention. :)
Re: pkg_add href regex
2017-08-04 0:37 GMT+03:00 Stuart Henderson <s...@spacehopper.org>:
> CC'ing ports@ in case people miss this on bugs@. Quick summary from
> earlier posts: some mirrors e.g. leaseweb, esc7, have directory listings
> with , which pkg_add's parser can't handle.
>
> On 2017/08/03 20:44, Taylor Stearns wrote:
>> On Wed, Aug 02, 2017 at 11:41:52PM +0100, Stuart Henderson wrote:
>> > Please send a diff -u and don't indent it.
>>
>> Here is the CVS diff -u:
>
> Thanks, that's readable now :)
>
> Normally I'd want to wait until espie@ is around for pkg_add changes
> but the leaseweb mirror is at the top of ftplist.cgi when fetched over
> https from a "new" IP address (it doesn't currently prioritize nearby
> mirrors like it does over http) so it's somewhat likely that fresh
> installs will be using this mirror by default, so it would be nice
> to get a fix committed sooner..
>
> Generally I agree with the diff except for one thing (below)
>
>> Index: PackageRepository.pm
>> ===
>> RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PackageRepository.pm,v
>> retrieving revision 1.145
>> diff -u -p -r1.145 PackageRepository.pm
>> --- PackageRepository.pm 20 Jun 2017 18:05:44 - 1.145
>> +++ PackageRepository.pm 3 Aug 2017 19:27:55 -
>> @@ -912,7 +912,7 @@ sub get_http_list
>> $error) or return;
>> while(<$fh>) {
>> chomp;
>> - for my $pkg (m/\<A\s+HREF=\"(.*?\.tgz)\"\>/gio) {
>> + for my $pkg (m/\<A\s+HREF=\"(.*?\.tgz)\"/gio) {
>> $pkg = $1 if $pkg =~ m|^.*/(.*)$|;
>> # decode uri-encoding; from URI::Escape
>> $pkg =~ s/%([0-9A-Fa-f]{2})/chr(hex($1))/eg;
>> Index: PackageRepository/HTTP.pm
>> ===
>> RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PackageRepository/HTTP.pm,v
>> retrieving revision 1.12
>> diff -u -p -r1.12 HTTP.pm
>> --- PackageRepository/HTTP.pm 27 Aug 2014 18:40:03 - 1.12
>> +++ PackageRepository/HTTP.pm 3 Aug 2017 19:27:55 -
>> @@ -280,7 +280,7 @@ sub get_directory
>> exit 1;
>> }
>> print "SUCCESS: directory $dname\n";
>> - for my $pkg ($r =~ m/\<A\s+HREF=\"(.+?)\.tgz\"\>/gio) {
>> + for my $pkg ($r =~ m/\<A\s+HREF=\"(.+?)\.tgz\"/gio) {
>> $pkg = $1 if $pkg =~ m|^.*/(.*)$|;
>> # decode uri-encoding; from URI::Escape
>> $pkg =~ s/%([0-9A-Fa-f]{2})/chr(hex($1))/eg;
>>
>
> The href doesn't have to immediately follow the " enough to cope, and I can't think of a downside, so there's a modified
> diff below that handles this.
>
> Any OKs for either Taylor's or my amended version?
>
> I've tested this with "pkg_add moo" from snapshot packages from *all*
> http mirrors, it works on all the non-broken ones (failures at unbr.br
> which doesn't use --delete, and ulisboa.pt which is down from my
> network, but these are obviously not a problem with the diff).
>
> Index: OpenBSD/PackageRepository.pm
> ===
> RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PackageRepository.pm,v
> retrieving revision 1.145
> diff -u -p -r1.145 PackageRepository.pm
> --- OpenBSD/PackageRepository.pm20 Jun 2017 18:05:44 - 1.145
> +++ OpenBSD/PackageRepository.pm3 Aug 2017 21:04:28 -
> @@ -912,7 +912,7 @@ sub get_http_list
> $error) or return;
> while(<$fh>) {
> chomp;
> - for my $pkg (m/\<A\s+HREF=\"(.*?\.tgz)\"\>/gio) {
> + for my $pkg (m/\<A[^>]*\s+HREF=\"(.*?\.tgz)\"/gio) {
> $pkg = $1 if $pkg =~ m|^.*/(.*)$|;
> # decode uri-encoding; from URI::Escape
> $pkg =~ s/%([0-9A-Fa-f]{2})/chr(hex($1))/eg;
> Index: OpenBSD/PackageRepository/HTTP.pm
> ===
> RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PackageRepository/HTTP.pm,v
> retrieving revision 1.12
> diff -u -p -r1.12 HTTP.pm
> --- OpenBSD/PackageRepository/HTTP.pm 27 Aug 2014 18:40:03 - 1.12
> +++ OpenBSD/PackageRepository/HTTP.pm 3 Aug 2017 21:04:28 -
> @@ -280,7 +280,7 @@ sub get_directory
> exit 1;
> }
> print "SUCCESS: directory $dname\n";
> - for my $pkg ($r =~ m/\<A\s+HREF=\"(.+?)\.tgz\"\>/gio) {
> + for my $pkg ($r =~ m/\<A[^>]*\s+HREF=\"(.+?)\.tgz\"/gio) {
> $pkg = $1 if $pkg =~ m|^.*/(.*)$|;
> # decode uri-encoding; from URI::Escape
> $pkg =~ s/%([0-9A-Fa-f]{2})/chr(hex($1))/eg;
>
Your version, Stuart, looks like okay for me (as in "I'd do the same tweak").
--
WBR,
Vadim Zhukov
Re: ldd crash
2016-07-21 22:52 GMT+03:00 Ilya Kaliman <ilya.kali...@gmail.com>: > Found on 5.9 amd64, can reproduce on latest amd64 snapshot. > > How to reproduce: > > mkdir some_dir > ld some_dir > this creates a.out (which is strange by itself - > shouldn't it print the error?) > ldd a.out > core dumps You do know what ldd does, don't you? It does run the binary you've just created. No wonder it coredumps, because it contains garbage. If you want to take a look on binary, use objdump (in particular, "objdump -p" when seeking for libraries - note, this will show only libraries used by the file you're investigating only, not every library that's loaded before main() being called), and not ldd. So just run "objdump -x a.out" on the binary you've created, and you'll see it's actually empty. Regarding ld... it just fails to fail properly when it encounters zero-size input. You'll get the same result with, e.g., /dev/null. Could you construct a patch for this? -- WBR, Vadim Zhukov
Re: pax(1) gets stuck in a loop creating intermediate directories
2016-02-16 1:22 GMT+03:00 Philip Guenther <pguent...@proofpoint.com>:
> On Sun, 14 Feb 2016, Philip Guenther wrote:
>> On Sun, 14 Feb 2016, Nicolas Bedos wrote:
> ...
>> > >Fix:
>> > I did some digging and it seems pax gets stuck in a loop after
>> > calling node_creat (file_subs.c) to create /tmp/foo/bar:
>> ...
>> > The first argument of chk_path seems to end with '/' because of the
>> > cpio format. I could not reproduce the problem with the ustar
>> > format. I did not look any further since I think it is chk_path
>> > which is at fault here.
>>
>> It doesn't occur when reading ustar format input because a filename with a
>> trailing slash is already specially handled there to provide compat with
>> the old tar format where directories are stored with a trailing slash.
>
> ...and since pax's tar format code only trims a single trailing slash, it
> will loop even in that case if you add more than one trailing slash.
>
> Indeed, if you add more than one trailing slash in general then it'll
> still hang despite your patch: to fix it the code needs to be able to
> detect when its reached an arbitrary number of trailing slashes.
>
> So, I think a diff like this is in order. This also lets it skip extra
> slashes in the middle of the path and avoid the checks that would be
> duplicated.
>
> Look good to everyone?
>
>
> --- file_subs.c 19 Mar 2015 05:14:24 - 1.47
> +++ file_subs.c 15 Feb 2016 09:35:57 -
> @@ -597,6 +597,7 @@ int
> chk_path(char *name, uid_t st_uid, gid_t st_gid)
> {
> char *spt = name;
> + char *next;
> struct stat sb;
> int retval = -1;
>
> @@ -613,6 +614,17 @@ chk_path(char *name, uid_t st_uid, gid_t
Hello, Philip.
I think we should change "if" to "while" in this function, too...
After that, okay zhuk@.
--
WBR,
Vadim Zhukov
Index: file_subs.c
===
RCS file: /cvs/src/bin/pax/file_subs.c,v
retrieving revision 1.47
diff -u -p -r1.47 file_subs.c
--- file_subs.c 19 Mar 2015 05:14:24 - 1.47
+++ file_subs.c 15 Feb 2016 23:24:40 -
@@ -597,13 +597,14 @@ int
chk_path(char *name, uid_t st_uid, gid_t st_gid)
{
char *spt = name;
+ char *next;
struct stat sb;
int retval = -1;
/*
* watch out for paths with nodes stored directly in / (e.g. /bozo)
*/
- if (*spt == '/')
+ while (*spt == '/')
++spt;
for (;;) {
@@ -613,6 +614,17 @@ chk_path(char *name, uid_t st_uid, gid_t
spt = strchr(spt, '/');
if (spt == NULL)
break;
+
+ /*
+* skip over duplicate slashes; stop if there're only
+* trailing slashes left
+*/
+ next = spt + 1;
+ while (*next == '/')
+ next++;
+ if (*next == '\0')
+ break;
+
*spt = '\0';
/*
@@ -625,7 +637,8 @@ chk_path(char *name, uid_t st_uid, gid_t
* required (do an access()).
*/
if (lstat(name, ) == 0) {
- *(spt++) = '/';
+ *spt = '/';
+ spt = next;
continue;
}
@@ -659,7 +672,8 @@ chk_path(char *name, uid_t st_uid, gid_t
set_pmode(name, ((sb.st_mode & FILEBITS) | S_IRWXU));
add_dir(name, , 1);
}
- *(spt++) = '/';
+ *spt = '/';
+ spt = next;
continue;
}
return(retval);
Re: ksh: backslash-escaped octal codes (\nnn) don't work properly in the prompt
2015-07-30 17:18 GMT+03:00 Vadim Ushakov igeekl...@gmail.com:
Hi,
According to the manpage, the escape sequence \nnn is expanded to the
octal character nnn in the PS1 prompt.
In fact, it is expanded to a garbage.
It seems that dopprompt() (in src/bin/ksh/lex.c) has the wrong
calculation:
n = cp[0] * 8 * 8 + cp[1] * 8 + cp[2];
snprintf(strbuf, sizeof strbuf, %c, n);
This should probably be:
n = ('0' - cp[0]) * 8 * 8 + ('0' - cp[1]) * 8 + ('0' - cp[2]);
snprintf(strbuf, sizeof strbuf, %c, n);
I do acknowledge the report. The corrected fix is below. I don't see
any potential breakage, nothing could rely on previous behaviour.
Thus I'm asking for okay to commit.
Too bad that I don't know how to make a test for this issue in
regress/usr.bin/ksh, though. It could tests stdin, stdout, stderr and
files, but I dunno how to test the shell prompt. Any ideas?
--
WBR,
Vadim Zhukov
Index: lex.c
===
RCS file: /cvs/src/bin/ksh/lex.c,v
retrieving revision 1.49
diff -u -p -r1.49 lex.c
--- lex.c 17 Dec 2013 16:37:06 - 1.49
+++ lex.c 30 Jul 2015 14:39:42 -
@@ -1370,7 +1370,8 @@ dopprompt(const char *sp, int ntruncate,
\\%c, *cp);
break;
}
- n = cp[0] * 8 * 8 + cp[1] * 8 + cp[2];
+ n = (cp[0] - '0') * 8 * 8 + (cp[1] - '0') * 8 +
+ (cp[2] - '0');
snprintf(strbuf, sizeof strbuf, %c, n);
cp += 2;
break;
Re: ksh: backslash-escaped octal codes (\nnn) don't work properly in the prompt
2015-07-30 17:18 GMT+03:00 Vadim Ushakov igeekl...@gmail.com:
Hi,
According to the manpage, the escape sequence \nnn is expanded to the
octal character nnn in the PS1 prompt.
In fact, it is expanded to a garbage.
It seems that dopprompt() (in src/bin/ksh/lex.c) has the wrong
calculation:
n = cp[0] * 8 * 8 + cp[1] * 8 + cp[2];
snprintf(strbuf, sizeof strbuf, %c, n);
This should probably be:
n = ('0' - cp[0]) * 8 * 8 + ('0' - cp[1]) * 8 + ('0' - cp[2]);
snprintf(strbuf, sizeof strbuf, %c, n);
Tweaked version was just committed as -r1.50 of lex.c, thanks!
--
WBR,
Vadim Zhukov
Re: k3b in i386
2014-08-11 22:41 GMT+04:00 macondo ironwindow2...@yahoo.com:
$ uname -a
OpenBSD foo.cpe.cableonda.net 5.5 GENERIC.MP#262 i386
k3b version 4.x
it doesn't recognize the cd in the cdrom and therefore will not start working.
Could you describe in detail, what actions do you make and what errors
do you get? What's printed on the text console if you start K3b from
terminal and try to access optical drive? And, please, provide full
dmesg. Output of those commands may help to diagnose the problem, too:
id
ls -l /dev/{r,}cd0c /usr/local/bin/k3b
Also, please note that there is no such thing as K3b 4.x, there is
KDE4-based K3b 2.1 instead. ;)
--
WBR,
Vadim Zhukov
Re: hw.sensors.acpithinkpad0.temp* disappear after suspend
I got the point. So it's up to sysadmin to trust or not the sensor data. Then original patch should be fine, except small nit - I think, it's better to reset only SENSOR_FINVALID flag instead of all. CC'ing ACPI guys for okays. -- WBR, Vadim Zhukov Index: acpithinkpad.c === RCS file: /cvs/src/sys/dev/acpi/acpithinkpad.c,v retrieving revision 1.30 diff -u -p -r1.30 acpithinkpad.c --- acpithinkpad.c 2 Apr 2013 00:46:47 - 1.30 +++ acpithinkpad.c 29 Jun 2013 08:41:46 - @@ -189,6 +189,8 @@ thinkpad_sensor_refresh(void *arg) sc-sc_sens[i].value = (tmp * 100) + 27315; if (tmp 127 || tmp -127) sc-sc_sens[i].flags = SENSOR_FINVALID; + else + sc-sc_sens[i].flags = ~SENSOR_FINVALID; } /* Read fan RPM */
Re: hw.sensors.acpithinkpad0.temp* disappear after suspend
Well, the point (for me) here was that if your sensor shows invalid
temperature once, it should not be trusted at all. If the problem
happens after resuming only, it's interesting what's in this register
actually - maybe we should just ignore some garbage by mask. Could
you apply the following patch instead, and send me what it prints
after a resume on your T520? It's better to run reboot-suspend-resume
cycle a few times, writing the number shown there each time, to
have a clue what's there.
--
WBR,
Vadim Zhukov
Index: acpithinkpad.c
===
RCS file: /cvs/src/sys/dev/acpi/acpithinkpad.c,v
retrieving revision 1.30
diff -u -p -r1.30 acpithinkpad.c
--- acpithinkpad.c 2 Apr 2013 00:46:47 - 1.30
+++ acpithinkpad.c 28 Jun 2013 16:28:02 -
@@ -187,8 +187,10 @@ thinkpad_sensor_refresh(void *arg)
aml_evalinteger(sc-sc_acpi, sc-sc_ec-sc_devnode,
sname, 0, 0, tmp);
sc-sc_sens[i].value = (tmp * 100) + 27315;
- if (tmp 127 || tmp -127)
+ if (tmp 127 || tmp -127) {
+ printf(%s: invalid temperature: %lld\n, DEVNAME(sc),
tmp);
sc-sc_sens[i].flags = SENSOR_FINVALID;
+ }
}
/* Read fan RPM */
Re: pf_query: query_counters() failed
24.03.2013 18:08 полÑзоваÑÐµÐ»Ñ Stuart Henderson s...@spacehopper.org напиÑал: On 2013/03/24 17:37, Vadim Zhukov wrote: 2013/3/24 Stuart Henderson s...@spacehopper.org: On 2013/03/24 15:00, alex wrote: Hi! With current snapshot i386 kernel ( dmesg.txt): #pfstat -c /etc/pfstat.conf -q -d /var/db/pfstat.d ioctl: DIOCGETSTATUS: Permission denied pf_query: query_counters() failed Update pfstat. No, he is right: $ sudo pfctl -si pfctl: DIOCGETSTATUS: Permission denied -- WBR, Vadim Zhukov Your kernel and userland are not in sync. More technically, missing make includes in sys/ before rebuilding pfctl. :) Sorry for stupidity... But ENOPERM is, probably, not the best answer in this case - ENOENT should match better, know?
Re: suspend/resume broken on T410i with new kms snapshot
21.03.2013 4:14 полÑзоваÑÐµÐ»Ñ Dawe dawed...@gmx.de напиÑал: On Mar 21, 2013 01:45, Vadim Zhukov wrote: 21.03.2013 0:03 Vadim Zhukov persg...@gmail.com ??: 2013/3/20 Vadim Zhukov persg...@gmail.com: 20.03.2013 15:54 Dawe dawed...@gmx.de ??: Hi, reporting just in case this isn't already known for my hardware (the kms undeadly article [1] suggests to me it's not): Suspend stopped working on my T410i with the latest amd64 snapshot (Mar 20) After typing zzz the screen blackens and the power and the moon-shaped leds keep blinking for ever. Then, only a hard reset helps. Besides from the known issues in the undeadly article everything else seems to be fine. Thanks a lot for the work and the funding! Same here, X201i. The real reason was last commit to acpi_machdep.c: http://marc.info/?l=openbsd-cvsm=136367562026379w=2 You can revert sys/amd64/amd64/acpi_machdep.c to -r1.52 and rebuild kernel. For those who interested, it's -r1.46 of sys/i386/i386/acpi_machdep.c for i386. Just fixed in -CURRENT. Yes, just tested the new kernel. Thanks a lot. All thanks should go to kettenis@, mlarkin@ and deraadt@. :)
Re: suspend/resume broken on T410i with new kms snapshot
20.03.2013 15:54 полÑзоваÑÐµÐ»Ñ Dawe dawed...@gmx.de напиÑал: Hi, reporting just in case this isn't already known for my hardware (the kms undeadly article [1] suggests to me it's not): Suspend stopped working on my T410i with the latest amd64 snapshot (Mar 20) After typing zzz the screen blackens and the power and the moon-shaped leds keep blinking for ever. Then, only a hard reset helps. Besides from the known issues in the undeadly article everything else seems to be fine. Thanks a lot for the work and the funding! Same here, X201i. [1] http://www.undeadly.org/cgi?action=articlesid=20130320095845mode=expanded OpenBSD 5.3-current (GENERIC.MP) #15: Tue Mar 19 23:48:46 MDT 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 6210174976 (5922MB) avail mem = 6037155840 (5757MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0010 (78 entries) bios0: vendor LENOVO version 6IET68WW (1.28 ) date 07/12/2010 bios0: LENOVO 25184QG acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET ASF! SLIC BOOT SSDT TCPA SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) IGBE(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) EXP5(S4) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5 CPU M 430 @ 2.27GHz, 2527.45 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM 2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC cpu0: 256KB 64b/line 8-way L2 cache cpu0: apic clock running at 132MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5 CPU M 430 @ 2.27GHz, 2527.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM 2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC cpu1: 256KB 64b/line 8-way L2 cache cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i5 CPU M 430 @ 2.27GHz, 2527.00 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM 2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC cpu2: 256KB 64b/line 8-way L2 cache cpu3 at mainbus0: apid 5 (application processor) cpu3: Intel(R) Core(TM) i5 CPU M 430 @ 2.27GHz, 2527.00 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM 2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC cpu3: 256KB 64b/line 8-way L2 cache ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus -1 (EXP3) acpiprt5 at acpi0: bus -1 (EXP4) acpiprt6 at acpi0: bus 13 (EXP5) acpicpu0 at acpi0: C3, C1, PSS acpicpu1 at acpi0: C3, C1, PSS acpicpu2 at acpi0: C3, C1, PSS acpicpu3 at acpi0: C3, C1, PSS acpipwrres0 at acpi0: PUBS acpitz0 at acpi0: critical temperature is 100 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 not present acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 cpu0: Enhanced SpeedStep 2527 MHz: speeds: 2267, 2266, 2133, 1999, 1866, 1733, 1599, 1466, 1333, 1199 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel Core Host rev 0x02 vga1 at pci0 dev 2 function 0 Intel HD Graphics rev 0x02 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: apic 1 int 16 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) Intel 3400 MEI rev 0x06 at pci0 dev 22 function 0 not configured em0 at pci0 dev 25 function 0 Intel 82577LM rev 0x06: msi, address 00:26:2d:fb:c7:02 ehci0 at pci0 dev 26 function 0 Intel 3400 USB rev 0x06: apic 1 int 23 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 Intel 3400 HD Audio rev 0x06: msi azalia0: codecs: Conexant/0x5069, Intel/0x2804, using Conexant/0x5069 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 3400 PCIE rev 0x06: msi pci1 at ppb0 bus 2 ppb1 at pci0 dev 28 function 1 Intel 3400 PCIE rev 0x06: msi pci2 at ppb1 bus 3 iwn0 at pci2 dev 0 function 0 Intel WiFi Link 1000 rev 0x00: msi, MIMO 1T2R,
Re: suspend/resume broken on T410i with new kms snapshot
21.03.2013 0:03 полÑзоваÑÐµÐ»Ñ Vadim Zhukov persg...@gmail.com напиÑал: 2013/3/20 Vadim Zhukov persg...@gmail.com: 20.03.2013 15:54 полÑзоваÑÐµÐ»Ñ Dawe dawed...@gmx.de напиÑал: Hi, reporting just in case this isn't already known for my hardware (the kms undeadly article [1] suggests to me it's not): Suspend stopped working on my T410i with the latest amd64 snapshot (Mar 20) After typing zzz the screen blackens and the power and the moon-shaped leds keep blinking for ever. Then, only a hard reset helps. Besides from the known issues in the undeadly article everything else seems to be fine. Thanks a lot for the work and the funding! Same here, X201i. The real reason was last commit to acpi_machdep.c: http://marc.info/?l=openbsd-cvsm=136367562026379w=2 You can revert sys/amd64/amd64/acpi_machdep.c to -r1.52 and rebuild kernel. For those who interested, it's -r1.46 of sys/i386/i386/acpi_machdep.c for i386. Just fixed in -CURRENT.
Re: ksh bug
24.01.2013 15:38 полÑзоваÑÐµÐ»Ñ ja...@cieti.lv напиÑал: Hello! If I type r r in console or xterm, like: $ r r I get ksh.core. It works on i386 5.2 and amd64 current. Check output of which r and alias | grep ^r= commands first. And, please, post dmesg.
Re: ksh bug
24.01.2013 16:08 полÑзоваÑÐµÐ»Ñ Otto Moerbeek o...@drijf.net
напиÑал:
Infinite recursion..
$ f() {
f
}
$ f
blows up as well.
Yes, but cyclic fc -e - will kill your history as a bonus. :)
