12.0-RELEASE kernel hangs on Dell Precision 7920
Hi there, I've installed FreeBSD/amd64 12.0-RELEASE on this beefy Dell Precision 7920 Tower workstation, but it does not boot unless I disable "Memory Map IO above 4GB" option in BIOS (UEFI): the kernel hangs right after "ACPI APIC Table: " line. Interestingly, it also won't boot if I disable NUMA (Non-Uniform Memory Access). This is for vanilla GENERIC kernel. Is this something known? Any ideas? I'd happily test patches, etc. ./danfe P.S. Ubuntu 16.04 LTS boots just fine on this box with default settings. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
On Thu, Oct 04, 2018 at 11:38:46AM -0600, Warner Losh wrote: > ... > I'd also suggest that rl stands in stark contrast to the cs, wb, sn, smc, > sf, tl, tx and vr drivers, which nobody has mentioned in this thread, and > which I doubt are in use in any FreeBSD system of any age today. Warner, I had mentioned [*] that I'm using sf(4), would you please be more careful when collecting "NICs still in use" data? We really do need a wiki page and carefully relect all the feedback we've received so far and also upcoming one. ./danfe [*] Message-ID: <20181004084411.ga50...@freebsd.org> ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
On Thu, Oct 04, 2018 at 08:43:33AM -0600, Warner Losh wrote: > As far as I know, none of the drivers listed could do 1Gbps. Right. My point was that original proposal put 10/100 drivers into one basket, which is IMHO not fair: 10Mbps cards are rarely seen and used, 100mbps are not, just like 1000bps ones. That said, I'm okay with deorbiting NICs that cannot do more than 10mbps. Cards that can do at least 100mbps should stay. Following up on Ricks' question, seeing a good example of modernization a certain driver would help interested people/hw owners to keep drivers for their cards viable. ./danfe ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
On Thu, Oct 04, 2018 at 02:26:44PM +, Mark Linimon wrote: > On Thu, Oct 04, 2018 at 08:44:11AM +0000, Alexey Dokuchaev wrote: > > OK I guess I can understand removing 10 (I personally haven't seen > > one in a very long time) but 100 are omnipresent and most of my NICs > > are in fact 100. > > Sigh. If you really plan to still be using i386 and 10/100 ether in > 2024, perhaps you should consider NetBSD. I don't quite understand why are you grouping 10/100 vs. 1000 rather than 10 vs. 100/1000. ./danfe ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
On Wed, Oct 03, 2018 at 09:05:16PM +, Brooks Davis wrote: > FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md) > outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12 Holy shit! OK I guess I can understand removing 10 (I personally haven't seen one in a very long time) but 100 are omnipresent and most of my NICs are in fact 100. > and remove them in FreeBSD 13 to reduce the burden of maintaining and > improving the network stack. Looking at the commits they require near zero maintenance. What exactly is the burden here? Another question: why the fuck FreeBSD likes to kill non-broken, low-volatile and perfectly working stuff? We offer probably the best NIC driver support on the block, yet you're proposing to shrink one of the few areas where we shine. WTF?! > The current list of drivers slated for REMOVAL is: > > ae, bfe, bm, cs, dme, ed, ep, ex, fe, pcn, rl, sf, smc, sn, > ste, tl, tx, txp, vx, wb, xe ae(4) was used in Asus EeePC 701/900 which are still popular among hackers. My home router uses sf(4) happily. It's a dual-port card and I don't want to look for expensive and completely needless replacement. Other people have already told you about ed/rl/etc. > Please reply to this message with nominations to the exception list. As it can be seen this list tends to cover nearly all 100 cards, yet no one (pardon me if I missed those) asks for 10. So how about making this proposal cover only 10 cards, if you can't resist the itch to remove something from the tree? ./danfe ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Clock not ticking during S3
On Tue, Oct 01, 2013 at 01:12:38PM +0200, Dominic Fandrey wrote: The system is sent to S3 at this point and woken 4 days later. This is how it comes up: 27 Sep 23:07:03 ntpd[3045]: no servers reachable 27 Sep 23:19:54 ntpd[3045]: synchronized to 83.170.1.225, stratum 2 27 Sep 23:19:54 ntpd[3045]: time correction of 306709 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. Roughly 3 and a half days of time missing. I've never seen anything like it before. This is my system. FreeBSD [...] 9.2-PRERELEASE FreeBSD [...] amd64 Not sure about amd64, but at least on i386, device pmtimer is required to be in kernel config for timekeeping while sleeping. ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: panic with if_iwi(4) upon netif restart
On Wed, Jul 04, 2012 at 06:51:56PM +0200, Bernhard Schmidt wrote: On Tuesday 19 June 2012 07:28:11 Alexey Dokuchaev wrote: On Mon, May 07, 2012 at 08:28:50PM +0200, Bernhard Schmidt wrote: does ps in kgdb reveal multiple instances of wpa_supplicant running? If so, this seems to be the well known devd+netif+supplicant+newstate race/missing refcount. Wanna try attached patch? Bernhard, Sorry it took so long to get back. With your patch applied, I haven't seen this panic for a while, however, double instances of wpa_supplicant still persist. So I think you can commit it, but underlying race remains to be fixed. Ok, thanks. The patch is indeed supposed to only fix the panics. The underlying problem is that a netif restart results in 2 calls to netif wlan0 start, one through the call itself the other due an event sent to devd. wpa_supplicant itself has a small window were it is possible that 2 instances are attached to one resource. I have yet to find a solution for this without adding any regressions. Funny thing: I've just tried 9-stable on this laptop of mine, and it paniced immediately inside iwi_auth_and_assoc() again once I've run wpa_supplicant (this time I did not do any of netif restart dances). Applying the same patch fixed it for me and allowed to have working network (typing through it right now). Haven't tried -current yet, but it looks like iwi(4) is unusable at least in 9.2. Can we have this patch committed while real solution is being worked on? It looks like it's going to take a while, and I'd like to have working iwi(4) like, uhm, now. ;-) ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: fusefs-kmod does not work on 8-STABLE?
On Mon, Apr 15, 2013 at 10:41:36PM -0400, Ryan Stone wrote: On Fri, Apr 12, 2013 at 10:28 AM, Alexey Dokuchaev da...@nsu.ru wrote: I've found the culprit: the problem is in this command of the build: ld -Bshareable -d -warn-common -o hello.ko.debug hello.kld I had put /usr/local/bin in my $PATH before /usr/bin for a reason I don't currently recall, and have binutils-2.23.1 installed. As a result, ld(1) in the quoted line above was called from /usr/local/bin/ld, [...] Is this for i386? When compiling modules with newer versions of ld I had to add the following flags to the ld invocation to get the module to work: Yes, this is for i386. -u __start_set_sysinit_set -u __start_set_sysuninit_set \ -u __start_set_sysctl_set -u __start_set_modmetadata_set \ -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ -u __stop_set_sysctl_set -u __stop_set_modmetadata_set Hmm. Adding these does help, indeed. How did you come up with this list? Is it documented anywhere, or just the result of careful readelf/objdump examination? Thanks! ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: fusefs-kmod does not work on 8-STABLE?
On Tue, Apr 16, 2013 at 01:21:32PM +0200, Dimitry Andric wrote: On 2013-04-16 08:14, Alexey Dokuchaev wrote: -u __start_set_sysinit_set -u __start_set_sysuninit_set \ -u __start_set_sysctl_set -u __start_set_modmetadata_set \ -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ -u __stop_set_sysctl_set -u __stop_set_modmetadata_set These are module start/stop symbols, which get optimized away by newer versions of binutils. We fixed it in head when binutils 2.17.50 was imported, here: http://svn.freebsd.org/changeset/base/215137 This fix could probably also be used for stable/8. It is most likely too late to get into 8.4, though. Personally I do not care for 8.4 (or any release), but would definitely appreciate if you could merge it to stable/8, thanks! ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: fusefs-kmod does not work on 8-STABLE?
On Fri, Apr 12, 2013 at 07:12:39PM +0200, Dimitry Andric wrote:
Does anyone have a clue why new ld(1) plays so badly with our system
toolchain on 8.x (at least)?
Maybe because there is almost 10 years difference between those
implementations? :-)
In any case, to figure out what is different, just try linking the
kernel module with the system ld and the ports ld, and comparing
readelf -a output.
Good idea. I've uploaded both outputs if someone wants to take a look.
Not surprisingly, bad output is shorter: readelf(1) reported only 16
section headers vs. good 18 (missing .got, .gnu_debuglink, and empty
.bss, yet having .eh_frame instead). Haven't look more closely yet:
http://193.124.210.26/readelf.bad
http://193.124.210.26/readelf.good
Or upload both module versions somewhere, so we can all have a look.
Sure, at the same URL, hello{.c,_bad.ko,_good.ko}. Although it should be
pretty easy to reproduce locally: just install fresh devel/binutils, put
$localbase/bin in front of your $path, and rebuild hello.ko (or any your
favorite module).
./danfe
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: fusefs-kmod does not work on 8-STABLE?
On Wed, Apr 10, 2013 at 12:27:10PM +0700, Alexey Dokuchaev wrote: I've got puzzled with the fact that fusefs-kmod apparently does not on recent 8-STABLE: it builds and loads, but I don't see normal fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.19 like I do on 9-STABLE (installed on the same laptop with almost identical kernel config). The result is that /dev/fuse0 never gets created, and any fuse mount attempt results in this message: fuse: failed to open fuse device: No such file or directory I've traced the problem down a bit, it seems to be due to some weird brokenness of building modules outside the kernel: .ko file loads, but modevent() functions apparently does not execute at all. Also, nvidia.ko can reveal this (or related) bug by spitting messages like this: link_elf: symbol linux_ioctl_unregister_handler undefined This behavior was reported by arundel@ back in 2009 on -current@, but the root cause was never found. http://lists.freebsd.org/pipermail/freebsd-current/2009-September/011975.html http://markmail.org/message/7opthxniqc5ncv6h ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: fusefs-kmod does not work on 8-STABLE?
On Fri, Apr 12, 2013 at 05:17:46PM +0700, Alexey Dokuchaev wrote: On Wed, Apr 10, 2013 at 12:27:10PM +0700, Alexey Dokuchaev wrote: I've got puzzled with the fact that fusefs-kmod apparently does not on recent 8-STABLE: it builds and loads, but I don't see normal fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.19 like I do on 9-STABLE (installed on the same laptop with almost identical kernel config). The result is that /dev/fuse0 never gets created, and any fuse mount attempt results in this message: fuse: failed to open fuse device: No such file or directory I've traced the problem down a bit, it seems to be due to some weird brokenness of building modules outside the kernel: .ko file loads, but modevent() functions apparently does not execute at all. I've found the culprit: the problem is in this command of the build: ld -Bshareable -d -warn-common -o hello.ko.debug hello.kld I had put /usr/local/bin in my $PATH before /usr/bin for a reason I don't currently recall, and have binutils-2.23.1 installed. As a result, ld(1) in the quoted line above was called from /usr/local/bin/ld, which brought in all the weird things I was observing: failure of fusefs-kmod, failure of simple hello world KLD, link_elf: symbol blah undefined messages when loading snd_hda(4) and nvidia(4) drivers. How, does anyone have a clue why new ld(1) plays so badly with our system toolchain on 8.x (at least)? ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
fusefs-kmod does not work on 8-STABLE?
Hey all, I've got puzzled with the fact that fusefs-kmod apparently does not on recent 8-STABLE: it builds and loads, but I don't see normal fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.19 like I do on 9-STABLE (installed on the same laptop with almost identical kernel config). The result is that /dev/fuse0 never gets created, and any fuse mount attempt results in this message: fuse: failed to open fuse device: No such file or directory Quick googling did not give me any good clues; perhaps someone here on the list knows better how to remedy this problem? Thanks, ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 memstick install panics on boot
On Fri, Dec 14, 2012 at 10:40:56AM +0700, Alexey Dokuchaev wrote: On Thu, Dec 13, 2012 at 10:23:49PM -0500, Glen Barber wrote: If the memstick panics, I am not sure how much good the kernel symbols will do for you. It's OK, as long as they are provided, I should be able to modify the memstick contents (like, after rw-mounted it) and copy debug-enabled kernel in /boot. On the second thought (try, actually) they are not too much helpful indeed, as I cannot get crashdump for post-mortem analysis (when symbols become useful), since panic happens so early debugger apparently has no idea of where to store the dump. It seems I have to debug it the hard way (hello printf's). Is it possible to cross build amd64 10.0 kernels on i386 8.3 machine? ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 memstick install panics on boot
On Fri, Dec 14, 2012 at 11:50:06AM +0200, Andriy Gapon wrote: It looks like you obtained the boot messages using some sort of a remote console? Yes; luckily this box has serial port (real, on-board one). If yes, you can try to use kgdb for a live remote debugging. I thought of it, but last time I tried I could get rid of GDB: no debug ports present message in dmesg. :-( Maybe it was due to USB-serial adapter, and with real serial port it would not be a problem. ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: panic in AcpiExSystemMemorySpaceHandler [Was: 9.1 memstick install panics on boot]
On Fri, Dec 14, 2012 at 11:48:10AM +0200, Andriy Gapon wrote: Could you please obtain acpidump output using Ubuntu? Yup, I already did [1]. Here is the what's inside: all.bin dump of all tables dsdt.bin dump of DSDT (original) dsdt.dsl decompiled DSDT dsdt.aml recompiled DSDT (from dsdt.dsl) [1] http://193.124.210.26/lenovo.tgz ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: kgdb + uart [Was: 9.1 memstick install panics on boot]
On Fri, Dec 14, 2012 at 12:40:23PM +0200, Andriy Gapon wrote: uart(4): 0x00080 use this port for remote kernel debugging Thanks, that did the magic. The problem, however, is that kgdb from i386 does not like amd64 kernel image, and I do not have any other amd64 box in the vicinity. Not sure how feasible would it be to build amd64-target yet i386-host kgdb. ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: kgdb + uart
On Fri, Dec 14, 2012 at 01:22:12PM +0200, Andriy Gapon wrote: Yeah, kgdb and target kernel must closely match each other. I guess that the machine does not support amd64 mode? Which machine? :-) My laptop can do i386 only, as it has old Dothan CPU. Lenovo box (victim) is E5500, which I want to use as amd64, but you've given me an idea: if this problem is not amd64-specific, I might be able to trigger it with 10.0/i386 and then remotely debug from my laptop. I will try it tomorrow, thanks! ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 memstick install panics on boot
On Thu, Dec 13, 2012 at 12:19:12PM +0200, Andriy Gapon wrote: Just a general note that nowadays booting without ACPI especially on laptops would not get you very far in 99% cases. IMO, it's pointless to try. I know, I just wanted to isolate a problem. Will you be able to try head on this system? This could have been fixed in more recent ACPICA imports. stable/9 seems have ACPICA from many months ago. Do we have memstick.img snapshots for -CURRENT somewhere? Can only boot via USB this time. ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 memstick install panics on boot
On Thu, Dec 13, 2012 at 05:36:35AM -0500, Glen Barber wrote: https://snapshots.glenbarber.us/Latest/ It is a few days behind though. I've tried 10.0 image from it; still getting (apparently the same) panic [1]. It seems that something is wrong with AML, but I cannot tell much without debug symbols. Glen, since you include kernel debugger in you snapshots, do you think you can ship those .symbols as well? :-) ./danfe [1] http://193.124.210.26/10.0-acpi.dmesg ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 memstick install panics on boot
On Thu, Dec 13, 2012 at 10:23:49PM -0500, Glen Barber wrote: On Thu, Dec 13, 2012 at 10:07:47PM -0500, Glen Barber wrote: They are included in the ISO. Meh... I did not pay attention to the subject too closely, it seems. If the memstick panics, I am not sure how much good the kernel symbols will do for you. I cannot build them into the memstick without changing the Makefiles, which I intentionally do not do so the images are what you would expect from a -RELEASE ISO. It's OK, as long as they are provided, I should be able to modify the memstick contents (like, after rw-mounted it) and copy debug-enabled kernel in /boot. Not need to regenerate anything on your side, thanks! ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
9.1 memstick install panics on boot
Hey folks, Was going to try 9.1/amd64 on this Lenovo box with E5500 I have here at $work. Unfortunately it panics immediately upon boot [1]. Seems it be ACPI-related, as disabling it allows the boot to proceed a little further but still panic [2]. Ubuntu 12.04 LTS booted and worked just fine on this box, yet I could not get anywhere with any memstick.img since 8.0. Any idea what's going on here? I've tried dumping DSDT and rebuilding it, did not help. Verbose bootlogs can be found here: [1] http://193.124.210.26/9.1-acpi.dmesg [2] http://193.124.210.26/9.1-noacpi.dmesg ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Resume broken in 8.3-PRERELEASE
On Tue, Aug 28, 2012 at 11:56:56AM +0300, Konstantin Belousov wrote: On Tue, Aug 28, 2012 at 09:07:51AM +0700, Alexey Dokuchaev wrote: Before zzz'ing: db show intrcnt irq1: atkbd0168 irq9: acpi0 8300 irc12: psm0 2 irq14: ata0 6301 irq16: bge0 uhci3 13 irq23: uhci0 ehci0 2 cpu0: timer 7306385 irq256: hdac0 30 After (within a minute after botched resume) db show intrcnt irq1: atkbd0479 irq9: cdpi0 8379 Was the output pasted verbatim ? I am curious about the irq9 name mangling in the second paste. Sorry, just rerun the test, no mangling, it was a typo on my behalf due to copying by hand. ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Resume broken in 8.3-PRERELEASE
On Mon, Mar 05, 2012 at 07:10:22AM +0100, Hans Petter Selasky wrote: On Monday 05 March 2012 05:17:59 Alexey Dokuchaev wrote: On Sat, Mar 03, 2012 at 09:11:29AM +0100, Hans Petter Selasky wrote: On Friday 02 March 2012 20:25:32 Jung-uk Kim wrote: Try the attached patch. At least, it fixed my problem. I've committed your patch with some minor modifications. http://svn.freebsd.org/changeset/base/232448 Unfortunately, it does not fix resume for me; and hw.usb.no_shutdown_wait flipping did not make any difference either. Any other ideas? Particularly, I'm curious why disabling all USB modules still does not allow this laptop to resume. What are USB debugging techniques? USB debugging: Have options USB_DEBUG in kernel config. Then set xxx.debug = 15 under hw.usb, typically hw.usb.uhub.debug=15 Today I've csupped to latest RELENG_8 (hoping that maybe the problem was fixed during last few months), rebuilt the kernel with USB_DEBUG option. After fresh reboot, the following snippet releately pop up on the console (hand-copied): usb_needs_explore: usb_bus_powerd: bus=0xc55cccf0-- bus= number changes usb_bus_powerd: Recomputing power masks uhub_explore: udev=0xc5647400 addr=1 -- udev= number changes uhub_read_port_status: port 1, wPortStatus=0x0100, wPortChange=0x, err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 2, wPortStatus=0x0100, wPortChange=0x, err=USB_ERR_NORMAL_COMPLETION (USB-CRC32 has plugged in, no other USB devices) Aroung zzz(8) time (keyboard die upon wake-up as described earlier with 100% CPU load -- fans are at full burst) debug mode yielded these: uhub_child_pnpinfo_string: device not on bub uhub_child_location_string: device not on bub uhub_child_pnpinfo_string: device not on bub usb_bus_powerd: bus=0xc55e2c78 usb_bus_powerd: Recomputing power masks uhub_read_port_status: port 1, wPortStatus=0x0500, wPortChange=0x, err=USB uhub_read_port_status: port 2, wPortStatus=0x0500, wPortChange=0x, err=USB ... up to port 8 ... uhub_read_port_status: port 8, wPortStatus=0x0500, wPortChange=0x, err=USB usual (disconnected) messages usb_buf_port_set_device: bus 0xc55cccf0 devices[2] = 0 usb_needs_explore: usb_needs_explore: usb_needs_explore: usb_needs_explore: usb_needs_explore: uhub0: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus4 uhub0: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus1 ... UHCI also found on usbus 2, 3, 0 (in that order) uhub_attach: depth=0 selfpowered=1, parent=0, parent-selfpowered=0 uhub_attach: Getting HUB descriptior uhub_attach: turn on port 1 power uhub_attach: turn on port 1 power uhub_attach: turn on port 1 power uhub_attach: turn on port 1 power uhub_attach: turn on port 1 power uhub_attach: turn on port 2 power uhub_attach: turn on port 2 power uhub_attach: turn on port 2 power uhub_attach: turn on port 2 power uhub1: 2 ports with 2 removable, self powered ... usb_needs_explore: loop quoted above repeats; system unusable Any ideas? ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Resume broken in 8.3-PRERELEASE
On Mon, Aug 27, 2012 at 05:34:54PM +0200, Hans Petter Selasky wrote: If the USB HC is feeding too many such IRQ's it will be stuck. However, if you see that uhub_read_port_status() is called, the kernel is at least running, though it might be that some IRQ is stuck, hence the 100% CPU usage. Could you try to get some IRQ stats? Before zzz'ing: db show intrcnt irq1: atkbd0168 irq9: acpi0 8300 irc12: psm0 2 irq14: ata0 6301 irq16: bge0 uhci3 13 irq23: uhci0 ehci0 2 cpu0: timer 7306385 irq256: hdac0 30 After (within a minute after botched resume) db show intrcnt irq1: atkbd0479 irq9: cdpi0 8379 irc12: psm0 2 irq14: ata0 6377 irq16: bge0 uhci3 26 irq23: uhci0 ehci0 5 cpu0: timer 7731880 irq256: hdac0 34 Not too much difference. Anything else I might get from DDB? Unfortunately, I am yet unable to save crashdump for later gdb analysis. ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: panic with if_iwi(4) upon netif restart
On Mon, May 07, 2012 at 08:28:50PM +0200, Bernhard Schmidt wrote: On Mon, May 7, 2012 at 5:54 AM, Alexey Dokuchaev da...@nsu.ru wrote: Weird panic occurs to me here with iwi(4) based laptop when trying to hook up to WPA-protected network with service netif restart. Kernel and userland are not strictly in sync, with the latter lagging behind couple of months, but presumably this fact should not matter on stable branch. does ps in kgdb reveal multiple instances of wpa_supplicant running? If so, this seems to be the well known devd+netif+supplicant+newstate race/missing refcount. Wanna try attached patch? Bernhard, Sorry it took so long to get back. With your patch applied, I haven't seen this panic for a while, however, double instances of wpa_supplicant still persist. So I think you can commit it, but underlying race remains to be fixed. ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: panic with if_iwi(4) upon netif restart
On Mon, May 07, 2012 at 08:28:50PM +0200, Bernhard Schmidt wrote: does ps in kgdb reveal multiple instances of wpa_supplicant running? Yes, grepping /var/crash/core.txt.0 shows two wpa_supplicant processes, one in -/Rs state and another in select/Ds. If so, this seems to be the well known devd+netif+supplicant+newstate race/missing refcount. Wanna try attached patch? Thanks, I will. ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
panic with if_iwi(4) upon netif restart
Folks,
Weird panic occurs to me here with iwi(4) based laptop when trying to hook
up to WPA-protected network with service netif restart. Kernel and
userland are not strictly in sync, with the latter lagging behind couple
of months, but presumably this fact should not matter on stable branch.
I was only able to get online by manually running wpa_supplicant(8) and
dhclient(8). if_iwi(4) loaded after system fully boots (i.e. manually after
login).
# kgdb /boot/kernel/kernel /var/crash/vmcore.0
...
(kgdb) bt
#0 doadump () at pcpu.h:231
#1 0xc045cc37 in db_fncall (dummy1=1, dummy2=0, dummy3=-1065923936,
dummy4=0xe787e8a4 ) at /home/danfe/fbsd/src/8/sys/ddb/db_command.c:548
#2 0xc045d014 in db_command (last_cmdp=0xc071a0fc, cmd_table=0x0, dopager=1)
at /home/danfe/fbsd/src/8/sys/ddb/db_command.c:445
#3 0xc045d152 in db_command_loop ()
at /home/danfe/fbsd/src/8/sys/ddb/db_command.c:498
#4 0xc045ef0e in db_trap (type=12, code=0)
at /home/danfe/fbsd/src/8/sys/ddb/db_main.c:229
#5 0xc051009e in kdb_trap (type=12, code=0, tf=0xe787eb1c)
at /home/danfe/fbsd/src/8/sys/kern/subr_kdb.c:548
#6 0xc06789ef in trap_fatal (frame=0xe787eb1c, eva=3319362005)
at /home/danfe/fbsd/src/8/sys/i386/i386/trap.c:972
#7 0xc0678d56 in trap_pfault (frame=0xe787eb1c, usermode=0, eva=3319362005)
at /home/danfe/fbsd/src/8/sys/i386/i386/trap.c:894
#8 0xc0679bba in trap (frame=0xe787eb1c)
at /home/danfe/fbsd/src/8/sys/i386/i386/trap.c:562
#9 0xc06643cc in calltrap ()
at /home/danfe/fbsd/src/8/sys/i386/i386/exception.s:168
#10 0xc5cf0b48 in iwi_auth_and_assoc (sc=0xc521e800, vap=0xc5bf9000)
at /home/danfe/fbsd/src/8/sys/modules/iwi/../../dev/iwi/if_iwi.c:2888
#11 0xc5cf125c in iwi_newstate (vap=0xc5bf9000, nstate=IEEE80211_S_AUTH,
arg=192)
at /home/danfe/fbsd/src/8/sys/modules/iwi/../../dev/iwi/if_iwi.c:1005
#12 0xc5d15848 in ieee80211_newstate_cb (xvap=0xc5bf9000, npending=1)
at
/home/danfe/fbsd/src/8/sys/modules/wlan/../../net80211/ieee80211_proto.c:1652
#13 0xc051abfe in taskqueue_run_locked (queue=0xc5c432c0)
at /home/danfe/fbsd/src/8/sys/kern/subr_taskqueue.c:250
#14 0xc051b222 in taskqueue_thread_loop (arg=0xc54e2074)
at /home/danfe/fbsd/src/8/sys/kern/subr_taskqueue.c:387
#15 0xc04b6eb9 in fork_exit (callout=0xc051b1a0 taskqueue_thread_loop,
arg=0xc54e2074, frame=0xe787ed28)
at /home/danfe/fbsd/src/8/sys/kern/kern_fork.c:876
#16 0xc0664474 in fork_trampoline ()
at /home/danfe/fbsd/src/8/sys/i386/i386/exception.s:275
(kgdb) f 11
#11 0xc5cf125c in iwi_newstate (vap=0xc5bf9000, nstate=IEEE80211_S_AUTH,
arg=192)
at /home/danfe/fbsd/src/8/sys/modules/iwi/../../dev/iwi/if_iwi.c:1005
1005iwi_auth_and_assoc(sc, vap);
(kgdb) l
1000 * for the ASSOC status to come back from the firmware.
1001 * Otherwise we need to issue the association request.
1002 */
1003if (vap-iv_state == IEEE80211_S_AUTH)
1004break;
1005iwi_auth_and_assoc(sc, vap);
1006break;
1007default:
1008break;
1009}
(kgdb) f 10
#10 0xc5cf0b48 in iwi_auth_and_assoc (sc=0xc521e800, vap=0xc5bf9000)
at /home/danfe/fbsd/src/8/sys/modules/iwi/../../dev/iwi/if_iwi.c:2888
2888rs.nrates = ni-ni_rates.rs_nrates;
(kgdb) l
2883
2884/* the rate set has already been negotiated */
2885memset(rs, 0, sizeof rs);
2886rs.mode = mode;
2887rs.type = IWI_RATESET_TYPE_NEGOTIATED;
2888rs.nrates = ni-ni_rates.rs_nrates;
2889if (rs.nrates IWI_RATESET_SIZE) {
2890DPRINTF((Truncating negotiated rate set from %u\n,
2891rs.nrates));
2892rs.nrates = IWI_RATESET_SIZE;
Feel free to ask for more information.
./danfe
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_8 kernel as of Apr 14 does not boot
On Tue, Apr 17, 2012 at 08:08:40PM +0700, Eugene Grosbein wrote: I guess, Alexey just tries to make smallest possible kernel just for fun :-) You are correct. Not for the size reasons though, but I want to be able to change as much as possible on the fly, without a reboot, and I cannot kldunload kernel yet. ;-) Another thing is that, while this is kinda unsupported configuration, it should work, even being an edge case. So it's a good test if our kernel has no hidden dependencies which would inhibit use of a module when it exists. Personally I do not see much benefits in having mem/io as modules, but if they are provided, I should be able to load them from the loader. If they must be compiled in, I suggest we stop shipping them as modules so not to confuse people (even that one must specially use nodevice to exclude them). ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_8 kernel as of Apr 14 does not boot
On Tue, Apr 17, 2012 at 08:40:37AM -0400, John Baldwin wrote: Hmm, this has been broken for a long time on HEAD and 9 it seems. However, there you get compile breakage (as acpi is no longer supported as a module in 9+) if you try to build a kernel with 'nodevice mem'. Yes, I am aware. Unfortunately, I am frightened to upgrade to 9.x as I have no confidence that it behaves well on my laptop. I still do not know how to fix 8.x after January which broke suspend/resume for me (EDIT: see below!). Hmm, mp_machdep.c also breaks. That is probably true on i386 as well, and has been true even on 7.x. (That is, you can't use 'nodevice mem' and 'SMP' in the same kernel.) Right, I have appropriate comment about it in my kernel config file. :-) OTOH, what are you trying to gain by putting mem.ko into a module rather than part of the base kernel? Do you just want no /dev/mem file or are you trying to disable all of the MTRR support as well? No, no, nothing other than checking how far can I go in putting everything possible into modules and loading them from /boot/loader.conf. I was not aware it affects MTRR support... It may be that we need to rethink what goes into mem.ko and have it only exclude /dev/mem but always leave MTRR support enabled. Hmm, this is interesting. I've been waiting for you to MFC r232742 to RELENG_8 as jkim@ mentioned that these are features that could be responsible for broken suspend/resume on i386. Are you saying that having loading mem.ko as module could affect certain registers restoration, and thus preventing correct resume? I've just tried to zzz/resume several times in a row with latest 8.x kernel with io/mem compiled in. Maybe I am speaking too fast, but guess what: keyboard works now, network service are accessible, bluetooth mouse works, etc. Unbelievable. My stupid nodevice gimmick prevented me from having working resume, LOL. I think that if we continue to install mem.ko as module, it should be clearly documented that results of such setup might be quite different from defaults. Thanks for pieces of valuable wisdom John. ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_8 kernel as of Apr 14 does not boot
On Tue, Apr 17, 2012 at 09:46:43PM +0700, Alexey Dokuchaev wrote: I've just tried to zzz/resume several times in a row with latest 8.x kernel with io/mem compiled in. Maybe I am speaking too fast, but guess what: keyboard works now, network service are accessible, bluetooth mouse works, etc. Unbelievable. My stupid nodevice gimmick prevented me from having working resume, LOL. Alas, fresh reboot -- and it all as bad as before. Need to debug more... ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_8 kernel as of Apr 14 does not boot
On Mon, Apr 16, 2012 at 01:37:29PM +0700, Eugene Grosbein wrote: 16.04.2012 11:26, Alexey Dokuchaev пишет: Just update my 8.x kernel sources last weekend, and newly built kernel did not boot for me: link_elf: symbol mem_range_softc undefined KLD file acpi.ko - could not finalize loading kernel trap 12 with interrupts disabled Try to add 'device mem' to your kernel configuration. :-) I explicitly have nodevice mem and nodevice io in my config. They are being loaded from /boot/loader.conf. This worked fine for quite a while. I will try to have it compiled-in, but would still prefer it fixed, or in case it cannot be fixed and mem.ko cannot be loaded separately from now on, appropriate entry in UPDATING. ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RELENG_8 kernel as of Apr 14 does not boot
Hi, Just update my 8.x kernel sources last weekend, and newly built kernel did not boot for me: link_elf: symbol mem_range_softc undefined KLD file acpi.ko - could not finalize loading kernel trap 12 with interrupts disabled This is stripped down kernel with everything possible loaded from modules. Any ideas? Did not see any warnings in UPDATING... ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Resume broken in 8.3-PRERELEASE
On Sat, Mar 03, 2012 at 09:11:29AM +0100, Hans Petter Selasky wrote: On Friday 02 March 2012 20:25:32 Jung-uk Kim wrote: Try the attached patch. At least, it fixed my problem. I've committed your patch with some minor modifications. http://svn.freebsd.org/changeset/base/232448 Unfortunately, it does not fix resume for me; and hw.usb.no_shutdown_wait flipping did not make any difference either. Any other ideas? Particularly, I'm curious why disabling all USB modules still does not allow this laptop to resume. What are USB debugging techniques? ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Resume broken in 8.3-PRERELEASE
On Thu, Mar 01, 2012 at 04:55:03PM -0500, Jung-uk Kim wrote: On Thursday 01 March 2012 01:53 pm, Hans Petter Selasky wrote: What is output from usbconfig as root, before and after suspend/resume ? Before suspend (just after reboot, this output is identical to pre/post SVN r229370): ugen0.1: UHCI root HUB Intel at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen1.1: UHCI root HUB Intel at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen2.1: UHCI root HUB Intel at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen3.1: UHCI root HUB Intel at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen4.1: EHCI root HUB Intel at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen0.2: US232B FTDI at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen3.2: Biometric Coprocessor STMicroelectronics at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON After resume (kernel from Jan 1): all lines are the same, except that last two lines are swapped (ugen3.2 is listed before ugen0.2). Presence of US232B does not affect behavior; ugen3.2 is built-in finger print scanner, and since in USB2 there is no separate ugen(4), I don't know how to selectively disable it. Man page for ugen(4) however exists. :-) It does not make a difference for me (i.e., usb suspend/resume still broken) but I think I found a typo: --- sys/dev/usb/controller/usb_controller.c (revision 232365) +++ sys/dev/usb/controller/usb_controller.c (working copy) @@ -407,7 +407,7 @@ usb_bus_suspend(struct usb_proc_msg *pm) USB_BUS_UNLOCK(bus); - bus_generic_shutdown(bus-bdev); + bus_generic_suspend(bus-bdev); usbd_enum_lock(udev); Same thing here, does not seem to improve anything. It might suspend, resume (with keyboard working), then die on next suspend completely. Or it may die on the first suspend (without suspending -- fans are spinning, screen is black and no response to anything except hard power-off), this actually happens more often. ./danfe P.S. Also, doing ps in debugger shows that acpiconf(8) is running in the userland upon resume (and hang). Not sure if it helps or not though. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Resume broken in 8.3-PRERELEASE
On Fri, Mar 02, 2012 at 08:48:13AM +0100, Hans Petter Selasky wrote: If the reset doesn't work, then try to enable hw.usb.uhub.debug=15 and see what port change events are coming. I don't see such oid hw.usb.uhub.debug. Perhaps it should be hw.usb.debug? If cfg=255 in usbconfig, then something is wrong. It seems they are all zeros, per the output I've sent earlier. ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Resume broken in 8.3-PRERELEASE
On Fri, Mar 02, 2012 at 04:14:08PM +0100, Hans Petter Selasky wrote: On Friday 02 March 2012 09:57:03 Alexey Dokuchaev wrote: On Fri, Mar 02, 2012 at 08:48:13AM +0100, Hans Petter Selasky wrote: If the reset doesn't work, then try to enable hw.usb.uhub.debug=15 and see what port change events are coming. I don't see such oid hw.usb.uhub.debug. Perhaps it should be hw.usb.debug? What about this? I've did hw.usb.debug=15, but didn't see anything new on the console. If cfg=255 in usbconfig, then something is wrong. It seems they are all zeros, per the output I've sent earlier. If they are all zeros, then everything is working like it should. If you can dump the device and configuration descriptors, then there is no USB problem. I can only dump this information *before* suspend, after resume I cannot do almost anything except breaking into debugger (but not being able to call doadump). I had to revert to earlier revision to call usbconfig(8) after resume. I'm thinking it might be some MICROCODE issue that causes the problem. Maybe we shouldn't reset the OHCI and EHCI and UHCI and XHCI before handing over to the MICROCODE suspend handler? Have a look in /sys/dev/usb/controller/xhci/ehci/ohci/uhci and search for suspend. OK, I will try and report back, thanks. ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Resume broken in 8.3-PRERELEASE
On Mon, Feb 27, 2012 at 10:22:38PM +0700, Alexey Dokuchaev wrote: On Mon, Feb 27, 2012 at 09:28:15PM +0700, Alexey Dokuchaev wrote: I was mistaken, the latest kernel with working resume is from Jan 4 00:00 UTC, kernel from Jan 4 01:00 UTC does not allow my laptop to come back from zzz(8) successfully. It seems that offending change is rev. 1.9.2.5 of sys/nfsclient/nfs_krpc.c by rmacklem@ (SVN rev 229450). I've redone my bisecting, now suspending/resuming around at least ten times in console with zzz(8). I must apologize to rmacklem@, his commit has nothing to do with it. Apparently, the culprit is SVN rev 229370 on 2012-01-03 09:15:54Z by hselasky@, which (ironically enough) supposed to bring better support for USB controller suspend and resume. Kernel csuped and built before this date resumes just fine for me. However, the problem might lay deeper: disabling all USB modules (I traditionally run slim kernels with everything down to io/mem offloaded into modules) does not fix the hang, see below. Selectively disabling UHCI or EHCI does not make any difference either. Debugging of this issue is, however, complicated by the fact that doing call doadump results in Dumping 68M: message (similar problem was reported[1] by glebius@ back in 2004), and then nothing happens except for IDE led light-up and frozen debugger, which makes post-mortem analysis with kgdb(1) impossible. Setting up serial console (since it's a laptop, the only possibility for me right now is to use some noname USB adapter via uftdi(4)) works, but kernel GDB does not like it. Perhaps I'm just not passing 0x80 flag correctly, but hint.uftdi.0.flags=0x80 does not work. Is GDB backend impossible with USB serial adapters, or I am just doing it wrong? What strikes me most is that even with plain kbdmux(4) or atkdb(4) I still cannot resume, even on previous (before r229370) kernels (the earliest I've tried is from Jan 1 00:00 UTC). Any debugging hints or patches to try are highly appreciated. Thus far, the latest kernel where resume works (with USB stuff enabled) is from Jan 3 19:15 UTC. Hans Petter, do you have any ideas about it? ./danfe [1] http://lists.freebsd.org/pipermail/freebsd-current/2004-May/027732.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Resume broken in 8.3-PRERELEASE
On Thu, Feb 23, 2012 at 09:57:14AM +0700, Alexey Dokuchaev wrote: Yesterday I've updated my laptop to the latest RELENG_8, it booted just fine, however, after coming out of suspend, keyboard does not work (well, almost: I can switch between consoles, Caps Lock works, but I cannot type anything, login, etc., break into debugger with Ctrl-Alt-Esc). Network does not work as well, and since fans are going up very fast, CPU consumption must be around 100%. Kernel from Jan 17th does not exhibit this problem. This is plain console, no X11. I was mistaken, the latest kernel with working resume is from Jan 4 00:00 UTC, kernel from Jan 4 01:00 UTC does not allow my laptop to come back from zzz(8) successfully. It seems that offending change is rev. 1.9.2.5 of sys/nfsclient/nfs_krpc.c by rmacklem@ (SVN rev 229450). To be sure, I've reverted just this change in the latest RELENG_8 sources -- and the problem goes away. Rick, how can I help you to debug this issue? I must admit I am confused how can NFS-related change break power-saving code path (suspend/resume). ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Resume broken in 8.3-PRERELEASE
On Mon, Feb 27, 2012 at 09:28:15PM +0700, Alexey Dokuchaev wrote: I was mistaken, the latest kernel with working resume is from Jan 4 00:00 UTC, kernel from Jan 4 01:00 UTC does not allow my laptop to come back from zzz(8) successfully. It seems that offending change is rev. 1.9.2.5 of sys/nfsclient/nfs_krpc.c by rmacklem@ (SVN rev 229450). To be sure, I've reverted just this change in the latest RELENG_8 sources -- and the problem goes away. Hmm, apparently the problem lies deeply/earlier. Backing out SVN rev 229450 allows me to resume twice, but third time it fails with the same symptoms as before (no keyboard while VTY switching works and screensaver fires, no network but ping(8) works, fans are bursting up). Stay tuned while I investigate more... ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Resume broken in 8.3-PRERELEASE
On Mon, Feb 27, 2012 at 10:47:49AM -0500, Rick Macklem wrote: Yes, I can't think of how r229450 would affect resume. All it does is clear the high order bit in an error reply from an NFS server, since that bit should never be set in an NFS error reply and, if set, it results in an mbuf list being free'd twice. True, although even if it helps triggering the real underlying bug, it's still weird. The bit is erroneously set by amd sometimes. If you are using amd, that might be related to the resume problem? No, I don't; I've deliberately disabled almost everything. ps: I suspect you saw it, but there was a recent thread related to known suspend/resume issues and discussed how they might be fixed in the future. Sorry, I don't remember which list or the exact subject line. Yes, I know what are you talking about. However, I don't recall if any one was experiencing the same symptoms as I do. ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Resume broken in 8.3-PRERELEASE
On Mon, Feb 27, 2012 at 12:46:07PM -0500, Jung-uk Kim wrote: Can you please try head and/or stable/9? FYI, Linux people found that some BIOSes can corrupt low 64KB between suspend/resume, which may cause strangeness like this. I worked around it in head (r231781) and stable/9 (r232088). Frankly speaking, last time I tried next stable to my running branch (not to mention head) I've gained more problems than solutions. :-) For example, when this laptop of mine was running stable/7 suspend/resume was working for months. I only (reluctantly) switched to stable/8 as I've noticed it's getting more attention that 7.x series, and annoying people with please MFC it to 7.x! calls does not look particularly nice. I remember that commit of your, though. I will try to backport at and report of the results, thanks! ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Resume broken in 8.3-PRERELEASE
Hi, Yesterday I've updated my laptop to the latest RELENG_8, it booted just fine, however, after coming out of suspend, keyboard does not work (well, almost: I can switch between consoles, Caps Lock works, but I cannot type anything, login, etc., break into debugger with Ctrl-Alt-Esc). Network does not work as well, and since fans are going up very fast, CPU consumption must be around 100%. Kernel from Jan 17th does not exhibit this problem. Plain console, no X11. Before I start to review all the changes in this period, perhaps someone can give me a hint which commit(s) might have caused it? Thanks, ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
kernel build broken on releng_6 due to camellia?
hi there, my usual kernel config did not work with fresh releng_6: === crypto (depend) @ - /usr/src/sys machine - /usr/src/sys/i386/include ln -s /usr/obj/usr/src/sys/VERSA/opt_param.h opt_param.h make: don't know how to make camellia.c. Stop *** Error code 2 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/VERSA. *** Error code 1 can it be caused by gnn@'s recent mfc? ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel build broken on releng_6 due to camellia?
On Mon, Dec 10, 2007 at 12:02:14PM +, Alexey Dokuchaev wrote: hi there, my usual kernel config did not work with fresh releng_6: sorry, false alarm. my supfile was bogus. ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Space missing in /usr/src/contrib/tcsh/nls/russian/set22
Hi! It seems that the following patch should be applied: === cut here === --- /usr/src/contrib/tcsh/nls/russian/set22.orig Tue Jan 15 04:46:19 2002 +++ /usr/src/contrib/tcsh/nls/russian/set22 Tue Jan 15 04:46:37 2002 @@ -1,7 +1,7 @@ $ $Id: set22,v 1.1 2001/03/18 19:06:39 christos Exp $ $ tc.func.c $set 22 -1 %S: \t ÐÅÒÅÏÐÒÅÄÅÌÅÎ × +1 %S: \t ÐÅÒÅÏÐÒÅÄÅÌÅÎ × 2 \nIncorrect passwd for %s\n 3 Faulty alias 'precmd' removed.\n 4 Faulty alias 'cwdcmd' removed.\n === cut here === ./danfe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Just curious on log rotating
Hello! Most logs are rotated via newsyslog (configured in /etc/newsyslog.conf), while accounting logs are rotated by /etc/periodic/daily/310...smthing. Why not to just rotate them all by newsyslog, so sysadmin would not need to mess with dozen files when tuning his box for log roration. Just wondering... -- WBR DAN Fe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
make -j
Hello! You see, I actually never had a clear vision of the whole `make -j' issue during making the world. Most notably, I'm not quite sure that it's perfectly OK to use it, that is, not being afraid that something would go wrong. So, I've been running make without specifying any of that -j numbers, just to be sure it won't break anything along the way. Right now I'm very curious about these questions: 1. Is it safe to build stable world/kernel with `-j n'? What are possible restrictions/limitations on n would be in this case? 2. What is optimal n? 3. Is there any way to specify the actual make (not gcc) options in make.conf, so I don't issue `make -j n' all the time, but simply type in `make target' and all my options would come in play? Thanks a lot! -- Regards, Alexey Dokuchaev aka DAN Fe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
