Re: akonadiconsole and SQL 57
On Wednesday, June 16, 2021 6:17:50 PM CEST Lizbeth Mutterhunt, Ph.D wrote: > hi people, > > first at the moment I have to short-cut my web as not at home and > /etc/rc.conf doesn't take my wlan0 interface; I changed rooter IP to > 192.168.8.1 and edited /etc/wpa_supplicant.conf. but still at booting the > field with the web stays "". I have mysql at startup. after recent update > on my grandmas notebook I have problems with loading kmail. > > Here's an excerpt of kmail start: > org.kde.pim.akonadiserver: Running DB initializer > org.kde.pim.akonadiserver: DB initializer done > Connecting to deprecated signal > QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) > Assertion failed: (param->buffer_length != 0), function There was a workaround posted here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255748#c16
geli_groups vs. fstab
I was testing geli_groups with a setup similar to the example here:
https://reviews.freebsd.org/D12644
The entries in rc.conf only work if the devices are not also listed in /etc/
fstab. The rc-script processes fstab entries before trying to attach the
geli_groups.
As workaround, I've edited /etc/rc.d/geli and exchanged the loops
"for group in ${geli_groups}; do" and "for provider in ${devices}; do".
Now it works as expected for me.
The commit message says:
This is helpful when the providers being attached are not used for boot,
and therefore the existing code to first try the cached password when
tasting the providers during boot does not apply.
I'm not sure how the "cached password" mechanism works. My rc-change might
break it.
Disclaimer: Tested on 13.0-RELEASE, but the rc-script ist the same in in
current.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HOWTO donate CPU to the fight against the Corona-virus
On Sunday, March 22, 2020 11:38:31 AM CEST Stefan Ehmann wrote: > On Saturday, March 21, 2020 12:07:55 PM CET Alexander Leidinger wrote: > > Quoting Stefan Ehmann (from Sat, 21 Mar 2020 > > > > 11:38:26 +0100): > > > On Thursday, March 19, 2020 8:57:45 AM CET Alexander Leidinger via > > > freebsd- > > > > > > stable wrote: > > >> Hi, > > >> > > >> if someone wants to donate some FreeBSD based CPU resources to the > > >> fight against the Corona-virus, here is a quick HOWTO in terms of > > >> installing the Folding@Home client on FreeBSD: > > >> > > >> https://www.leidinger.net/blog/2020/03/19/fighting-the-coronavirus-with > > >> -f > > >> ree bsd-foldinghome/ > > > > > > Unfortunately, (using a CPU slot for the same work unit) TPF is 2-3 > > > times > > > slower than on Ubuntu for me. Much of the speed difference seems to > > > be related > > > to libOpenCL. If remove libOpenCL on Ubuntu, it's still 20-30% faster > > > than > > > on FreeBSD. > > > > The pure CPU based code should be the same. Someone would have to > > trace / reverse engineer what is going on. > > I'm pretty sure now that libOpenCL is only relevant for GPU slots. > > I couldn't reproduce that the presence of libOpenCL.so has any effect on CPU > slots. Didn't make much sense anyway, something else must have been going > on. So there's probably no point in getting OpenCL to run on FreeBSD until > we have GPU rendering. > > The numbers displayed by FAHControl are rather strange: > * There is no discernible difference in speed if 1 or all CPU cores are used > (but top shows that 600% CPU cycles are burned) - happens on both Ubuntu > and Linuxolator > * According to the progress bar, Ubuntu completes 1% per minute, but > Linuxolator only 0.1% (for the same work unit) > > Don't know if the numbers displayed are bogus or there is really that much > of a difference. Maybe the issue is only related to a specific WU or to > AMD-CPUs. Just a short update: I've tested the port with a different WU and everything seems normal. Speed is comparable to Linux and multi-core also works as expected. My previous problems can probably be ignored, not sure what the problem actually was. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HOWTO donate CPU to the fight against the Corona-virus
On Saturday, March 21, 2020 12:07:55 PM CET Alexander Leidinger wrote: > Quoting Stefan Ehmann (from Sat, 21 Mar 2020 > > 11:38:26 +0100): > > On Thursday, March 19, 2020 8:57:45 AM CET Alexander Leidinger via > > freebsd- > > > > stable wrote: > >> Hi, > >> > >> if someone wants to donate some FreeBSD based CPU resources to the > >> fight against the Corona-virus, here is a quick HOWTO in terms of > >> installing the Folding@Home client on FreeBSD: > >> > >> https://www.leidinger.net/blog/2020/03/19/fighting-the-coronavirus-with-f > >> ree bsd-foldinghome/ > > > > Unfortunately, (using a CPU slot for the same work unit) TPF is 2-3 times > > slower than on Ubuntu for me. Much of the speed difference seems to > > be related > > to libOpenCL. If remove libOpenCL on Ubuntu, it's still 20-30% faster than > > on FreeBSD. > > The pure CPU based code should be the same. Someone would have to > trace / reverse engineer what is going on. I'm pretty sure now that libOpenCL is only relevant for GPU slots. I couldn't reproduce that the presence of libOpenCL.so has any effect on CPU slots. Didn't make much sense anyway, something else must have been going on. So there's probably no point in getting OpenCL to run on FreeBSD until we have GPU rendering. The numbers displayed by FAHControl are rather strange: * There is no discernible difference in speed if 1 or all CPU cores are used (but top shows that 600% CPU cycles are burned) - happens on both Ubuntu and Linuxolator * According to the progress bar, Ubuntu completes 1% per minute, but Linuxolator only 0.1% (for the same work unit) Don't know if the numbers displayed are bogus or there is really that much of a difference. Maybe the issue is only related to a specific WU or to AMD-CPUs. I've also tried https://fahbench.github.io/ but it's mainly targeted at GPUs and uses a different Core. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HOWTO donate CPU to the fight against the Corona-virus
On Thursday, March 19, 2020 8:57:45 AM CET Alexander Leidinger via freebsd- stable wrote: > Hi, > > if someone wants to donate some FreeBSD based CPU resources to the > fight against the Corona-virus, here is a quick HOWTO in terms of > installing the Folding@Home client on FreeBSD: > > https://www.leidinger.net/blog/2020/03/19/fighting-the-coronavirus-with-free > bsd-foldinghome/ > Unfortunately, (using a CPU slot for the same work unit) TPF is 2-3 times slower than on Ubuntu for me. Much of the speed difference seems to be related to libOpenCL. If remove libOpenCL on Ubuntu, it's still 20-30% faster than on FreeBSD. Don't know how stable the TPF numbers are, so numbers may be bogus. Will a CPU slot also use the GPU with libOpenCL or is it just using better optimized code? I tried to install libOpenCL but all I get is: OpenCL: Not detected: clGetPlatformIDs() returned -1001 Since there's no CUDA support for FreeBSD, I guess there is no point in trying getting GPU slots to work. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
sha256 speed
Hello, On my Ryzen the sha256 command is much slower than openssl dgst -sha256. For large files, openssl is more than 7 times faster in practice. You can also test it with the builtin benchmarks: sha256 -t openssl speed sha256 I think the reason is that openssl supports the SHA CPU extensions whereas libmd (used by sha256) does not. Any chance we can make the base sha256 faster? I guess there is some reason why we use libmd instead of openssl. https://reviews.freebsd.org/D2651 looks related but not sure it's still relevant. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G
On 11/14/18 5:41 AM, Conrad Meyer wrote: > You know what, I wonder if you're running into the CUR_TEMP_RANGE_SEL? > I.e., sometimes the CPU chooses to report on a range from 0-225C and > sometimes -49C-206C. I think someone else's 2990WX did the same > thing. I guess that patch never landed? 102°C - 49°C is the very > reasonable 53°C. > > Yeah, sigh, it never landed: https://reviews.freebsd.org/D16855 > > Ok I'll go ahead and commit that too. Applied to 12.0-BETA, Ryzen 7 2700 values are now in the 30-55C range. Looks reasonable. Thanks! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G
On 11/13/18 10:14 PM, Conrad Meyer wrote: > On Tue, Nov 13, 2018 at 1:04 PM Stefan Ehmann wrote: >> After kldload amdtemp I see the following sysctls: >> dev.cpu.0.temperature: 77.1C >> dev.amdtemp.0.core0.sensor0: 77.1C >> >> The temperature I see in BIOS is much lower (maybe around 40.0C). Don't >> know if just the offset is wrong or the numbers are completely bogus. >> >> Numbers from sysutils/xmbmon look saner but not sure if they are correct. > > You can adjust dev.amdtemp.N.sensor_offset as needed. By default, the > amdtemp sysctl gives you the unadjusted value. On different Ryzen > models the raw value is wrong by different amounts. E.g. on my 1950X, > I have sensor_offset set to "-27" to show correct temperature > readings. > > See this link for a table of offset values for various Ryzen models: > https://www.guru3d.com/articles-pages/amd-ryzen-7-2700-review,7.html Thanks for the link. The 2700 has an offset of 0 though (2700X has 10). And I'm seeing a difference of more than 30 degrees. I guess something else must be happening here. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G
On 11/13/18 10:40 PM, Daniel Eischen wrote: > >> On Nov 13, 2018, at 4:02 PM, Stefan Ehmann wrote: >> >>> On 11/13/18 8:59 PM, Daniel Eischen wrote: >>>> On Tue, 13 Nov 2018, Greg V wrote: >>>> >>>> >>>> >>>> On Tue, Nov 13, 2018 at 8:59 PM, Daniel Eischen >>>> wrote: >>>>> Greetings, >>>>> >>>>> I'm trying to track down a couple of things. amdtemp doesn't >>>>> report any temperature sensors, and acpi seems to have some >>>>> errors. Not sure if they are related. >>>>> >>>>> These are the ACPI-related warnings and errors during boot. >>>>> >>>>>Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has >>>>> valid Length but zero Address: 0x/0x1 >>>>> (20181031/tbfadt-796) >>>> >>>> I see this one on my R7 1700 / X370 system, seems harmless. >> >> I also see this warning on the X470-pro with Ryzen 7 2700 on 12.0-BETA. >> But I don't get the Firmware errors below. > > What BIOS version are you using? I'm running 13-current built from just a > few days ago. Never had any temp sysctls since initial install (beginning of > October). Latest Version (4024), but I think I've tried it before with an older version. Didn't notice any differences though. But I guess amdtemp is more dependent on the CPU than on the main board. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G
On 11/13/18 8:59 PM, Daniel Eischen wrote:
> On Tue, 13 Nov 2018, Greg V wrote:
>
>>
>>
>> On Tue, Nov 13, 2018 at 8:59 PM, Daniel Eischen
>> wrote:
>>> Greetings,
>>>
>>> I'm trying to track down a couple of things. amdtemp doesn't
>>> report any temperature sensors, and acpi seems to have some
>>> errors. Not sure if they are related.
>>>
>>> These are the ACPI-related warnings and errors during boot.
>>>
>>> Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has
>>> valid Length but zero Address: 0x/0x1
>>> (20181031/tbfadt-796)
>>
>> I see this one on my R7 1700 / X370 system, seems harmless.
I also see this warning on the X470-pro with Ryzen 7 2700 on 12.0-BETA.
But I don't get the Firmware errors below.
>>> acpi0: on motherboard
>>> Firmware Error (ACPI): Failure creating [\134_SB.SMIC],
>>> AE_ALREADY_EXISTS (20181031/dswload2-477)
>>> ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog
>>> (20181031/psobject-372)
>>> Firmware Error (ACPI): Failure creating [\134_SB.SMIB],
>>> AE_ALREADY_EXISTS (20181031/dsfield-803)
>>
>> Looks like people see these on Linux:
>>
>> https://forum.manjaro.org/t/unstable-behaviour-not-always-completely-booting/55823/5
>>
>>
>> Are you on the latest firmware ("BIOS") revision for your board?
>
> Yes, it's an ASUS Prime X-470 PRO, and I'm running with the latest
> BIOS from 2018 September 21, version 4024.
>
> https://www.asus.com/us/Motherboards/PRIME-X470-PRO/HelpDesk_BIOS/
>
After kldload amdtemp I see the following sysctls:
dev.cpu.0.temperature: 77.1C
dev.amdtemp.0.core0.sensor0: 77.1C
The temperature I see in BIOS is much lower (maybe around 40.0C). Don't
know if just the offset is wrong or the numbers are completely bogus.
Numbers from sysutils/xmbmon look saner but not sure if they are correct.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Good motherboard for Ryzen (first-gen)
On 9/22/18 4:53 AM, Eric van Gyzen wrote: I would like to build a Ryzen desktop. Can anyone recommend a good motherboard? I'm planning on a first-gen, because the second-gen has similar stability problems as the first-gen had, and AMD hasn't released errata for the second-gen yet (as far as I know...I would love to be wrong). I would like to be a cool kid with a Threadripper, but I can't justify the cost, so I'm thinking maybe a Ryzen 7 with /only/ 8 cores. :) Running Ryzen 7 2700 with Asus X470-PRO. No major problems so far. Minor issues: - powerd/amdtemp don't work correctly, I'll probably retest when 12-BETA is out - Linuxolator doesn't work (as petefrench pointed out) - Had a crash while backing up to external HDD but pretty sure the problem was a bad SATA connection The system does a lot of poudriere builds. Cannot comment on long-time stability, system is off at night. Ideally, I want an Intel NIC, ECC memory support, and a 3-year warranty. Board has an Intel igb NIC. According to the vendor "ECC support varies by CPU". But only found reports of ECC not working, not a single success story. The X370 board is a bit cheaper. Went for X470 because X370 boards may require firmware update for 2nd gen Ryzen. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Getting PID of socket client
On 09.07.2017 11:52, Johannes Lundberg wrote: Hi Yeah I forgot to mention the LOCAL_CREDS. It does not return the PID of the client process but i guess it could be expanded to include that instead of adding another option for that. I was only skimming the man page. Didn't see that cmsgcred contains the PID, but sockcred does not. Of course the PID in my sample output is also wrong (the UID is printed instead of the PID): $ ./unixstrserv02 PID of sender = 1001 Don't why the structs are not compatible, maybe because: "The process ID cmcred_pid should not be looked up (such as via the KERN_PROC_PID sysctl) for making security decisions. The sending process could have exited and its process ID already been reused for a new process." According to the commit log LOCAL_CREDS was obtained from NetBSD but I didn't investigate further. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Getting PID of socket client
On 09.07.2017 10:03, Johannes Lundberg wrote: Hi Without altering the client code (i.e. adding sendmsg(credentials)), is there anyway of getting the client PID (or path to binary) using the file descriptor returned by accept() on the server side? Similar to Linux's getsockopt with SO_PEERCRED option. You want the LOCAL_CREDS socket option from unix(4). There's also a FreeBSD sample in the UNIX network programming book. Source is available from http://unpbook.com/src.html With the following two changes it seems to work for me: unixstrserv02.c: set LOCAL_CREDS readcred.c: disable CONTROL_LEN check $ ./unixstrserv02 PID of sender = 1001 real user ID = 1001 real group ID = 1001 effective user ID = 1001 3 groups: 0 5 920 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SmartCard Reader on CURRENT
On 17.11.2016 10:44, O. Hartmann wrote: > Hello, > > I'm looking for a suitable SmartCard read with USB connection for 12-CURRENT > (and > probably 11-STABLE). We have lots of Omnikey 3121 devices at hand, but I > wasn't able to > make this type of SC reader working. it is recognised by the kernel as UGEN > device on the > USB bus. > > I tried to investigate what driver I need to use, but failed. The references > I found > referring to SC card daemones all point to a serial device like /dev/cuaUXX - > but as far > as I know, such a device is present if the UART<->USB has been recognised by > the > appropriate driver. > > So, the question is: do I miss something here (I'm not quite familiar with > USB/serial > devices)? > > If the device Omnikey HID 3121 is properly supported and I'm to dull to > figure this out - > please enlighten me! If there are aafordable alternatives (external or > internal for > add-on in a workstation) I would be glad to get your hint. On 11.0 the OMNIKEY 3121 works fine: # pkg install pcsc-lite ccid # echo 'pcscd_enable="YES"' >> /etc/rc.conf # service pcscd start For a simple test you can install security/pcsc-tools and run pcsc_scan or (g)scriptor. If you have problems, I suggest starting pcscd manually with # pcscd -f -d ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [patch] USB after second suspend/resume on ThinkPads.
On 16.06.2014 21:21, Edward Tomasz Napierała wrote: Hi. Patch below should fix a problem where USB stops working after _second_ suspend/resume, which happens on various ThinkPad models. Please test, and report both success stories and failures. If nothing comes up, I'll commit it in a week or so. (Btw, has anyone encountered the problem on hardware other than ThinkPads?) Fixed USB resume issues on T410 for me. At first I thought it didn't work, but then I noticed acpi_ibm needs to be loaded. Thanks! This has been a long-standing and annoying bug. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
wlan0/iwn: no upload statistics
Network monitoring tools show download traffic, but no upload data. systat -ifstat output: Interface Traffic PeakTotal wlan0 in 1.066 KB/s 16.155 KB/s 377.757 MB out 0.000 KB/s 0.000 KB/s0.000 KB Tested on amd64 CURRENT from few days ago. netword Card is: iwn0: Intel Centrino Ultimate-N 6300 mem 0xf200-0xf2001fff irq 17 at device 0.0 on pci3 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: wlan0/iwn: no upload statistics
On 07.06.2014 14:39, bycn82 wrote: Hi, Seem it was not clear in my original post: Only the wireless interface is affected. lo0 shows upload stats. More information is required. Please provide the output of the two commands below 1. sysctl -a | grep octets iwn0/wlan0 don't appear here: dev.em.0.mac_stats.good_octets_recvd: 0 dev.em.0.mac_stats.good_octets_txd: 0 2. uname -a FreeBSD tomorrow.pepperland 11.0-CURRENT FreeBSD 11.0-CURRENT #8 r267126: Fri Jun 6 06:14:13 CEST 2014 stefan@tomorrow.pepperland:/usr/obj/usr/src/sys/TOMORROW amd64 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Thinkpad T410: resume broken
On 21.05.2014 21:43, Jan Henrik Sylvester wrote: On 05/21/2014 21:22, Hans Petter Selasky wrote: On 05/21/14 21:16, Jan Henrik Sylvester wrote: Unfortunately, my USB mouse does not work anymore: After the first resume, it took a few seconds until it worked again (the build in touchpad was back immediately). After the second resume, it would not work anymore at all, even after reconnecting it to a different EHCI port. It does work at a XHCI, though, until the next resume. Anyhow, this is obviously not related to the original problem. Hi, USB controller are being reset at resume, so I think this indicates a more fundamental PCI/BUS problem. Looking through dmesg, it seems that other USB devices (build-in) are reappearing (Qualcomm Gobi 2000, Broadcom Bluetooth Device) after resume, just not the mouse. I can confirm this behavior. It already happened on 9.x. Devices plugged into the USB ports are not even powered. It's not just mouse, also USB hard disks for instance. Are these lines likely related? pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.PEG_: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP1: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP2: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP4: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP5: AE_BAD_PARAMETER I don't remember seeing these lines in 9.x. That doesn't necessarily mean they are not related. -- Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Thinkpad T410: resume broken
On 17.05.2014 01:39, Adrian Chadd wrote: Hm, okay. i wonder how we can diagnose this further. Do you have a video monitor? Can you try doing a suspend/resume with an external VGA screen attached? I booted with VGA as primary (and only) monitor. No real changes. The external monitor also remains blank when I resume on virtual console. Or connect it via ethernet and do a suspend/resume whilst logged in? I can do that. Any specific data you expect from that? Some more infos from today's testing: I also had one or two hangs during resume from Xorg with vt (similar to the sc hangs). If I restart Xorg, I get rid of the garbled X fonts/graphics (when resume is working) There are just too many options right now: sc/vt, X11/console, nvidia driver, internal display/external monitor, etc.. Are there any specific tests that could be useful? dmesg excerpts of a mostly working suspend/resume, don't know if related: When I start Xorg (9x) ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97) During suspend/resume: pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.PEG_: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP1: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP2: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP4: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP5: AE_BAD_PARAMETER ... NVRM: GPU at :01:00: GPU-bc3d36af-d7e7-bb30-dd7a-84afb0d14d75 NVRM: Xid (:01:00): 6, PE0001 ... NVRM: Xid (:01:00): 56, CMDre 0080 0005 0008 -- Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Thinkpad T410: resume broken
On 17.05.2014 14:20, John Baldwin wrote: On 5/16/14, 2:10 PM, Kevin Oberman wrote: On Fri, May 16, 2014 at 10:44 AM, Adrian Chadd adr...@freebsd.org wrote: Hi! I wonder what changed between 9.2-RELEASE and 10.0-RELEASE. Please poke me about this next week. I'm busy this week with work and maker faire but I will try to help you later. (It's possible something like ACPI updates or a driver update has broken things.) -a Does your kernel include VESA? My T320 behaved as you describe until I removed VESA from my kernel. I think using vt may also fix this without the need to remove VESA, bug I have not gotten around to confirming this. To be clear, vt does not fix resume. Using i915kms is what actually fixes resume when using Intel GPUs on the Thinkpad as i915kms is what actually turns the LCD backlight on during resume. You just have to use vt to have a useable console when you use i915kms. You can suspend/resume fine in X with syscons + i915kms, you just can't use your console if you do. If you are using the Nvidia GPU, then i915kms can't help you with turning the LCD backlight back on (and using vt shouldn't make any difference). VESA needs to be removed for i915kms, but I've no idea if it needs to be removed for Nvidia. The video reset code was reworked in 10 so that having VESA is supposed to be like using 'hw.acpi.reset_video=1' on 9, but in theory it works more often. The ACPI_PM setting to the kernel module along with removing VESA would seem like your best bet, but I see in follow-ups that that wasn't completely reliable. However, you can try using ACPI_PM with syscons, no need to use vt. I'm using nvidia graphics. Removing VESA with syscons actually worked today. ACPI_PM for the module isn't necessary, but doesn't seem to hurt either. Now it seems to work like in 9.2-RELEASE. Also, no hangs so far. I'm pretty sure I tested that setup yesterday without success. So either there was something wrong in yesterday's test or I changed something else in the meantime. Suspending when Xorg is not running still results in a black monitor after resume. But I'm not really sure if I've tried that in 9.2-RELEASE. -- Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Thinkpad T410: resume broken
Suspend/Resume is broken on my T410 using CURRENT from today. Resume was working fine on 9.2-RELEASE. 10.0-RELEASE and 10-STABLE don't work either. Symptoms: acpiconf -s3 sends it into sleep mode as expected In single user mode, it wakes up correctly, but the screen remains black. I tried with/without nvidia module loaded. It also happens with debug.acpi.suspend_bounce=1. I've tried all tips from https://wiki.freebsd.org/SuspendResume to no avail. In multi-user mode (especially when X is running) it doesn't wake up correctly most of the time: It powers up and the fan starts, but keyboard is not responding. Also, the power led pulsates, as if still in sleep mode. -- Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Thinkpad T410: resume broken
On 16.05.2014 22:51, Adrian Chadd wrote: Hi, Yeah. I'd really suggest trying with stable/10 or -HEAD with vt enabled and no VESA. Thanks for all replies. Using vt is definitely an improvement, but not perfect. (I've set hw.vga.textmode=1 because graphics mode is very slow. Don't know if that matters.) The text console still remains black if I try to resume from there. But there's some success suspending from X: Resume puts me back on the text console in a strange state, e.g., no text visible and a cursor blinking. After some time I can bring X back via CTRL-ALT-F9. Some of the graphics/fonts in X are garbled after resume. But it's still usuable. After that, also the virtual consoles work via CTRL-ALT-F1. But after a second resume, X was even more garbled and virtual consoles no longer worked. Setting ACPI_PM for x11/nvidia-driver doesn't seem to have any effects. -- Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
usbus seen as network devices
I've noticed that with 9.0-RC1, usbus[0-9] are seen as network interfaces. I figured this is need for usbdump to work. (This isuue has been raised before [1], but no helpful replies were given). I find this behavior rather annoying: 1) usbus0 is the default interface (in 8.2, my primary network interface was default) # tcpdump tcpdump: WARNING: usbus0: That device doesn't support promiscuous mode (BIOCPROMISC: Operation not supported) tcpdump: WARNING: usbus0: no IPv4 address assigned tcpdump: packet printing is not supported for link type USB: use -w 2) Various tools (netstat, tcpdump, wireshark, my network monotoring dockapp) now list 8 additional interfaces: # netstat -i NameMtu Network Address Ipkts Ierrs IdropOpkts Oerrs Coll usbus 0 Link#1 0 0 00 0 0 usbus 0 Link#2 0 0 00 0 0 ... 3) I can do rather silly things, that at best will do nothing: # ifconfig usbus0 10.0.0.1 # usbdump -i lo0 Some applications seem to check the link type, so that unsupported interfaces are not shown. But the behavior isn't even consistent in the base system: - ifconfig -a doesn't show usbus interfaces, but lets you happily configure them - tcpdump -D shows the interfaces, but bails out if you actually start capturing - netstat shows them - systat -ifstat only lists real interfaces Do all these applications need to be patched, or can this be fixed in a single place (in the kernel)? Is there a kernel option/sysctl/etc. to disable this behavior? I'm most likely not going to need usbdump in the foreseeable future. [1] http://lists.freebsd.org/pipermail/freebsd-stable/2011- September/063941.html -- Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic on 5.2 BETA: blockable sleep lock
On Fri, 2003-11-28 at 01:02, Don Lewis wrote: On 27 Nov, Stefan Ehmann wrote: On Wed, 2003-11-26 at 08:33, Don Lewis wrote: The problem is that selrecord() wants to lock a MTX_DEF mutex, which can cause a context switch if the mutex is already locked by another thread. This is contrary to what bktr_poll() wants to accomplish by calling critical_enter(). Strange enough that does not seem to happen with a kernel built without INVARIANTS and WITNESS. Does this make any sense or is this just by chance? You might try the patch below with WITNESS enabled. I don't have the hardware, so I can't test it. It compiles for me, but for all I know it could delete all your files if you run it. Any chance for getting this committed? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.2-BETA panic: page fault
This happens to me several times a day (cvsup from yesterday didn't
change anything). The panic message is always the same, the backtrace is
different though (but always seems to be file system related in some
way)
Here's one from today:
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for
details.
This GDB was configured as i386-undermydesk-freebsd...
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0505b53
stack pointer = 0x10:0xd7f2ea88
frame pointer = 0x10:0xd7f2eaa4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1253 (esd)
trap number = 12
panic: page fault
syncing disks, buffers remaining...
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0505b53
stack pointer = 0x10:0xd7f2e89c
frame pointer = 0x10:0xd7f2e8b8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1253 (esd)
trap number = 12
panic: page fault
Uptime: 1h19m23s
Dumping 383 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304
320 336 352 368
---
Reading symbols from /boot/kernel/snd_pcm.ko...done.
Loaded symbols for /boot/kernel/snd_pcm.ko
Reading symbols from /boot/kernel/snd_csa.ko...done.
Loaded symbols for /boot/kernel/snd_csa.ko
Reading symbols from /boot/kernel/bktr_mem.ko...done.
Loaded symbols for /boot/kernel/bktr_mem.ko
Reading symbols from
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/linux/linux.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/ext2fs/ext2fs.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/ext2fs/ext2fs.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/ntfs/ntfs.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/ntfs/ntfs.ko.debug
Reading symbols from /boot/kernel/bktr.ko...done.
Loaded symbols for /boot/kernel/bktr.ko
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc050f5a2 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:372
#2 0xc050f8f8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc068248c in trap_fatal (frame=0xd7f2e85c, eva=0)
at /usr/src/sys/i386/i386/trap.c:821
#4 0xc0682152 in trap_pfault (frame=0xd7f2e85c, usermode=0, eva=0)
at /usr/src/sys/i386/i386/trap.c:735
#5 0xc0681d63 in trap (frame=
{tf_fs = -1066729448, tf_es = 16, tf_ds = -1066205168, tf_edi =
-104931, tf_esi = 228, tf_ebp = -671946568, tf_isp = -671946616,
tf_ebx = 0, tf_edx = 16842753, tf_ecx = -1011687424, tf_eax =
-1011660928, tf_trapno = 12, tf_err = 0, tf_eip = -1068475565, tf_cs =
8, tf_eflags = 66178, tf_esp = -671946560, tf_ss = -1068475264}) at
/usr/src/sys/i386/i386/trap.c:420
#6 0xc06743d8 in calltrap () at {standard input}:94
#7 0xc0502b54 in lockmgr (lkp=0xc3b2e028, flags=0, interlkp=0xe4,
td=0xc06bfc1d) at /usr/src/sys/kern/kern_lock.c:228
#8 0xc0566d87 in vfs_busy (mp=0x0, flags=16, interlkp=0xc075d0e0,
td=0x0)
at /usr/src/sys/kern/vfs_subr.c:527
#9 0xc056cfff in sync (td=0xc0730dc0, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:132
#10 0xc050f0f6 in boot (howto=256) at
/usr/src/sys/kern/kern_shutdown.c:281
#11 0xc050f8f8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#12 0xc068248c in trap_fatal (frame=0xd7f2ea48, eva=0)
at /usr/src/sys/i386/i386/trap.c:821
#13 0xc0682152 in trap_pfault (frame=0xd7f2ea48, usermode=0, eva=0)
at /usr/src/sys/i386/i386/trap.c:735
#14 0xc0681d63 in trap (frame=
{tf_fs = -672006120, tf_es = -672006128, tf_ds = -1068105712,
tf_edi = -104931, tf_esi = 228, tf_ebp = -671946076, tf_isp =
-671946124, tf_ebx = 0, tf_edx = 16777217, tf_ecx = -1011687424, tf_eax
= -1011660928, tf_trapno = 12, tf_err = 0, tf_eip
Re: 5.2-BETA panic: page fault
On Sun, 2003-11-30 at 11:13, Stefan Ehmann wrote:
This happens to me several times a day (cvsup from yesterday didn't
change anything). The panic message is always the same, the backtrace is
different though (but always seems to be file system related in some
way)
Here's one from today:
As per request I made a (hopefully more useful) backtrace with a patched
gdb version:
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc050f5a2 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:372
#2 0xc050f8f8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc068248c in trap_fatal (frame=0xd7f2e85c, eva=0)
at /usr/src/sys/i386/i386/trap.c:821
#4 0xc0682152 in trap_pfault (frame=0xd7f2e85c, usermode=0, eva=0)
at /usr/src/sys/i386/i386/trap.c:735
#5 0xc0681d63 in trap (frame=
{tf_fs = -1066729448, tf_es = 16, tf_ds = -1066205168, tf_edi =
-104931, tf_esi = 228, tf_ebp = -671946568, tf_isp = -671946616,
tf_ebx = 0, tf_edx = 16842753, tf_ecx = -1011687424, tf_eax =
-1011660928, tf_trapno = 12, tf_err = 0, tf_eip = -1068475565, tf_cs =
8, tf_eflags = 66178, tf_esp = -671946560, tf_ss = -1068475264}) at
/usr/src/sys/i386/i386/trap.c:420
#6 0xc06743d8 in calltrap () at {standard input}:94
#7 0xc0505b53 in _mtx_lock_flags (m=0x0, opts=0,
file=0xc06bfc1d /usr/src/sys/kern/kern_lock.c, line=228)
at /usr/src/sys/kern/kern_mutex.c:214
#8 0xc0502b54 in lockmgr (lkp=0xc3b2e028, flags=0, interlkp=0xe4,
td=0xc06bfc1d) at /usr/src/sys/kern/kern_lock.c:228
#9 0xc0566d87 in vfs_busy (mp=0x0, flags=16, interlkp=0xc075d0e0,
td=0x0)
at /usr/src/sys/kern/vfs_subr.c:527
#10 0xc056cfff in sync (td=0xc0730dc0, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:132
#11 0xc050f0f6 in boot (howto=256) at
/usr/src/sys/kern/kern_shutdown.c:281
#12 0xc050f8f8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#13 0xc068248c in trap_fatal (frame=0xd7f2ea48, eva=0)
at /usr/src/sys/i386/i386/trap.c:821
#14 0xc0682152 in trap_pfault (frame=0xd7f2ea48, usermode=0, eva=0)
at /usr/src/sys/i386/i386/trap.c:735
#15 0xc0681d63 in trap (frame=
{tf_fs = -672006120, tf_es = -672006128, tf_ds = -1068105712,
tf_edi = -104931, tf_esi = 228, tf_ebp = -671946076, tf_isp =
-671946124, tf_ebx = 0, tf_edx = 16777217, tf_ecx = -1011687424, tf_eax
= -1011660928, tf_trapno = 12, tf_err = 0, tf_eip = -1068475565, tf_cs =
8, tf_eflags = 66178, tf_esp = 2, tf_ss = -1011660928}) at
/usr/src/sys/i386/i386/trap.c:420
#16 0xc06743d8 in calltrap () at {standard input}:94
#17 0xc0505b53 in _mtx_lock_flags (m=0x0, opts=0,
file=0xc06bfc1d /usr/src/sys/kern/kern_lock.c, line=228)
at /usr/src/sys/kern/kern_mutex.c:214
#18 0xc0502b54 in lockmgr (lkp=0xc3b2e028, flags=0, interlkp=0xe4,
td=0xc06bfc1d) at /usr/src/sys/kern/kern_lock.c:228
#19 0xc0566d87 in vfs_busy (mp=0x0, flags=0, interlkp=0x0, td=0x0)
at /usr/src/sys/kern/vfs_subr.c:527
#20 0xc056374c in lookup (ndp=0xd7f2ec00) at
/usr/src/sys/kern/vfs_lookup.c:559
#21 0xc0562fde in namei (ndp=0xd7f2ec00) at
/usr/src/sys/kern/vfs_lookup.c:183
#22 0xc05726ef in kern_mkdir (td=0xc3b34780, path=)
at /usr/src/sys/kern/vfs_syscalls.c:3230
#23 0xc0572699 in mkdir (td=0x0, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:3214
#24 0xc06827c0 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134546513, tf_esi =
-1077941929, tf_ebp = -1077944248, tf_isp = -671945356, tf_ebx = 0,
tf_edx = 134543200, tf_ecx = 134578233, tf_eax = 136, tf_trapno = 12,
tf_err = 2, tf_eip = 672183855, tf_cs = 31, tf_eflags = 582, tf_esp =
-1077944500, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1010
#25 0xc067442d in Xint0x80_syscall () at {standard input}:136
#26 0x2810b62f in ?? ()
(kgdb)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA panic: page fault
On Mon, 2003-12-01 at 01:10, Don Lewis wrote:
Can you reproduce this problem without bktr?
snip
You are getting a double panic, with the second happening during the
file system sync. The code seems to be be tripping over the same mount
list entry each time. Maybe the mount list is getting corrupted. Are
you using amd? Print *lkp in the lockmgr() stack frame.
You might want to add
KASSERT(mp-mnt_lock.lk_interlock !=NULL, vfs_busy: NULL mount
pointer interlock);
at the top of vfs_busy() and right before the lockmgr() call.
No, I'm not using amd.
(kgdb) print *lkp
$1 = {lk_interlock = 0x0, lk_flags = 0, lk_sharecount = 0, lk_waitcount
= 0,
lk_exclusivecount = 0, lk_prio = 0, lk_wmesg = 0x0, lk_timo = 0,
lk_lockholder = 0x0, lk_newlock = 0x0}
This is indeed just NULLs.
I haven't tried without bktr yet but I hope I'll have time for that (and
the KASSERT) tomorrow.
The panic only seems to happen when accessing my read-only mounted ext2
partition. Today I tried not to access any data there and uptime is
14h30min now. The panic always happened after a few hours. So this is
probably the core of the problem.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic on 5.2 BETA: blockable sleep lock
On Fri, 2003-11-28 at 01:02, Don Lewis wrote: On 27 Nov, Stefan Ehmann wrote: On Wed, 2003-11-26 at 08:33, Don Lewis wrote: The problem is that selrecord() wants to lock a MTX_DEF mutex, which can cause a context switch if the mutex is already locked by another thread. This is contrary to what bktr_poll() wants to accomplish by calling critical_enter(). Strange enough that does not seem to happen with a kernel built without INVARIANTS and WITNESS. Does this make any sense or is this just by chance? You might try the patch below with WITNESS enabled. I don't have the hardware, so I can't test it. It compiles for me, but for all I know it could delete all your files if you run it. Tested it a few times and no panics - seems to work fine. Tested it again without the patch: panics immediately after starting alevt (not xawtv as initially stated). Thanks ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic on 5.2 BETA: blockable sleep lock
On Fri, 2003-11-28 at 01:02, Don Lewis wrote:
On 27 Nov, Stefan Ehmann wrote:
On Wed, 2003-11-26 at 08:33, Don Lewis wrote:
The problem is that selrecord() wants to lock a MTX_DEF mutex, which can
cause a context switch if the mutex is already locked by another thread.
This is contrary to what bktr_poll() wants to accomplish by calling
critical_enter().
Strange enough that does not seem to happen with a kernel built without
INVARIANTS and WITNESS. Does this make any sense or is this just by
chance?
You might try the patch below with WITNESS enabled. I don't have the
hardware, so I can't test it. It compiles for me, but for all I know it
could delete all your files if you run it.
Unfortunately, after running the patched kernel some time I got a
slightly different panic:
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for
details.
This GDB was configured as i386-undermydesk-freebsd...
panic: blockable sleep lock (sleep mutex) sellck @
/usr/src/sys/kern/sys_generic.c:1145
panic messages:
---
panic: blockable sleep lock (sleep mutex) sellck @
/usr/src/sys/kern/sys_generic.c:1145
syncing disks, buffers remaining... 2248 2248 panic: mi_switch: switch
in a critical section
Uptime: 4m11s
Dumping 383 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304
320 336 352 368
---
Reading symbols from /boot/kernel/snd_pcm.ko...done.
Loaded symbols for /boot/kernel/snd_pcm.ko
Reading symbols from /boot/kernel/snd_csa.ko...done.
Loaded symbols for /boot/kernel/snd_csa.ko
Reading symbols from /boot/kernel/bktr_mem.ko...done.
Loaded symbols for /boot/kernel/bktr_mem.ko
Reading symbols from
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/linux/linux.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/ext2fs/ext2fs.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/ext2fs/ext2fs.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/ntfs/ntfs.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/ntfs/ntfs.ko.debug
Reading symbols from /boot/kernel/bktr.ko...done.
Loaded symbols for /boot/kernel/bktr.ko
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc050f482 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:372
#2 0xc050f7d8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc05174e5 in mi_switch () at /usr/src/sys/kern/kern_synch.c:470
#4 0xc050f16e in boot (howto=256) at
/usr/src/sys/kern/kern_shutdown.c:312
#5 0xc050f7d8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#6 0xc0535e19 in witness_lock (lock=0xc075c8a0, flags=8,
file=0xc06c4d72 /usr/src/sys/kern/sys_generic.c, line=1145)
at /usr/src/sys/kern/subr_witness.c:609
#7 0xc0505aaa in _mtx_lock_flags (m=0xc075c8a0, opts=0,
file=0xc06f10bc äLmÀ\t, line=-1009577024)
at /usr/src/sys/kern/kern_mutex.c:221
#8 0xc053a016 in selrecord (selector=0xc3d313c0, sip=0xc075c8a0)
at /usr/src/sys/kern/sys_generic.c:1145
#9 0xc4174981 in bktr_close () from /boot/kernel/bktr.ko
#10 0xc04c6650 in spec_poll (ap=0xd8cdbafc)
at /usr/src/sys/fs/specfs/spec_vnops.c:379
#11 0xc04c5a88 in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:122
#12 0xc057635c in vn_poll (fp=0x0, events=0, active_cred=0xc412b080,
td=0x0)
at vnode_if.h:537
#13 0xc0539851 in selscan (td=0xc3d313c0, ibits=0xd8cdbb9c,
obits=0xd8cdbb8c,
nfd=6) at /usr/src/sys/sys/file.h:272
#14 0xc05393bf in kern_select (td=0xc3d313c0, nd=6, fd_in=0xbfbfeb90,
fd_ou=0x0, fd_ex=0x0, tvp=0x0) at
/usr/src/sys/kern/sys_generic.c:816
#15 0xc0539026 in select (td=0x0, uap=0xd8cdbd14)
at /usr/src/sys/kern/sys_generic.c:720
#16 0xc06827e0 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1, tf_esi =
134598312, tf_ebp = -1077941208, tf_isp = -657605260, tf_ebx = 0, tf_edx
= 6, tf_ecx = -1077941360, tf_eax = 93, tf_trapno = 12, tf_err = 2,
tf_eip = 673044815, tf_cs = 31, tf_eflags = 658, tf_esp = -1077941444,
tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1010
#17 0xc067444d in Xint0x80_syscall () at {standard input}:136
(kgdb)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd
Re: panic on 5.2 BETA: blockable sleep lock
On Fri, 2003-11-28 at 10:31, Stefan Ehmann wrote: On Fri, 2003-11-28 at 01:02, Don Lewis wrote: On 27 Nov, Stefan Ehmann wrote: On Wed, 2003-11-26 at 08:33, Don Lewis wrote: The problem is that selrecord() wants to lock a MTX_DEF mutex, which can cause a context switch if the mutex is already locked by another thread. This is contrary to what bktr_poll() wants to accomplish by calling critical_enter(). Strange enough that does not seem to happen with a kernel built without INVARIANTS and WITNESS. Does this make any sense or is this just by chance? You might try the patch below with WITNESS enabled. I don't have the hardware, so I can't test it. It compiles for me, but for all I know it could delete all your files if you run it. Unfortunately, after running the patched kernel some time I got a slightly different panic: Please ignore the message above - this was the panic from an unpatched kernel - I was debugging the wrong core. Thanks again for quick help. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic on 5.2 BETA: blockable sleep lock
On Wed, 2003-11-26 at 08:33, Don Lewis wrote: The problem is that selrecord() wants to lock a MTX_DEF mutex, which can cause a context switch if the mutex is already locked by another thread. This is contrary to what bktr_poll() wants to accomplish by calling critical_enter(). Strange enough that does not seem to happen with a kernel built without INVARIANTS and WITNESS. Does this make any sense or is this just by chance? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA: giving up on 4 buffers (ata)
On Wed, 2003-11-26 at 19:37, Matthias Andree wrote: Hi, when I rebooted my 5.2-BETA (kernel about 24 hours old), it gave up on flushing 4 dirty blocks. I had three UFS1 softdep file systems mounted on one ATA drive, one ext2 file system on another ATA drive and one ext2 file system on a SCSI drive. Both ext2 file systems had been mounted read-only, so they can't have had dirty blocks. This is a known problem for nearly three months now (See PR 56675). It happens to me every time I shut down the system if i don't unmount my (read-only) ext2 file systems manually. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic on 5.2 BETA: blockable sleep lock
I got the following panic twice when starting xawtv using 5.2 BETA (CVS
from Oct 23)
panic: blockable sleep lock (sleep mutex) sellck
@/usr/src/sys/kern/sys_generic.c:1145
I don't think it is directly related to bktr since the last commit there
was ~3 months ago. Here is the dmesg output for completeness though.
bktr0: BrookTree 878 mem 0xdf103000-0xdf103fff irq 10 at device 12.0
on pci0
bktr0: Card has no configuration EEPROM. Cannot determine card make.
bktr0: IMS TV Turbo, Philips FR1236 NTSC FM tuner.
Here is a backtrace:
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for
details.
This GDB was configured as i386-undermydesk-freebsd...
panic: blockable sleep lock (sleep mutex) sellck @
/usr/src/sys/kern/sys_generic.c:1145
panic messages:
--
panic: blockable sleep lock (sleep mutex) sellck @
/usr/src/sys/kern/sys_generic.c:1145
syncing disks, buffers remaining... 3023 3023 panic: mi_switch: switch
in a critical section
Uptime: 6m28s
Dumping 383 MB
16 32 48 64 80[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 96
112 128 144 160 176 192 208 224 240[CTRL-C to abort] [CTRL-C to abort]
[CTRL-C to abort] 256 272 288 304 320 336 352 368
--
Reading symbols from /boot/kernel/snd_pcm.ko...done.
Loaded symbols for /boot/kernel/snd_pcm.ko
Reading symbols from /boot/kernel/snd_csa.ko...done.
Loaded symbols for /boot/kernel/snd_csa.ko
Reading symbols from /boot/kernel/bktr.ko...done.
Loaded symbols for /boot/kernel/bktr.ko
Reading symbols from /boot/kernel/bktr_mem.ko...done.
Loaded symbols for /boot/kernel/bktr_mem.ko
Reading symbols from
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/linux/linux.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/ext2fs/ext2fs.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/ext2fs/ext2fs.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/ntfs/ntfs.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/ntfs/ntfs.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/if_tap/if_tap.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/if_tap/if_tap.ko.debug
Reading symbols from /boot/kernel/netgraph.ko...done.
Loaded symbols for /boot/kernel/netgraph.ko
Reading symbols from /boot/kernel/ng_ether.ko...done.
Loaded symbols for /boot/kernel/ng_ether.ko
Reading symbols from /boot/kernel/ng_bridge.ko...done.
Loaded symbols for /boot/kernel/ng_bridge.ko
Reading symbols from /boot/kernel/ng_socket.ko...done.
Loaded symbols for /boot/kernel/ng_socket.ko
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc051502c in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:372
#2 0xc05153b7 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc051d0c5 in mi_switch () at /usr/src/sys/kern/kern_synch.c:470
#4 0xc0514d18 in boot (howto=256) at
/usr/src/sys/kern/kern_shutdown.c:312
#5 0xc05153b7 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#6 0xc053c010 in witness_lock (lock=0xc076cf40, flags=8,
file=0xc06d2139 /usr/src/sys/kern/sys_generic.c, line=1145)
at /usr/src/sys/kern/subr_witness.c:609
#7 0xc050b57a in _mtx_lock_flags (m=0xc3a56dc0, opts=0,
file=0xc06ff79c \037#nÀ\t, line=-1065955520)
at /usr/src/sys/kern/kern_mutex.c:221
#8 0xc0540436 in selrecord (selector=0xc076cf40, sip=0xc3a56dc0)
at /usr/src/sys/kern/sys_generic.c:1145
#9 0xc08509f1 in bktr_poll () from /boot/kernel/bktr.ko
#10 0xc04cbb00 in spec_poll (ap=0xd38ceafc)
at /usr/src/sys/fs/specfs/spec_vnops.c:379
#11 0xc04caf38 in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:122
#12 0xc057ca1c in vn_poll (fp=0x0, events=0, active_cred=0xc3c85380,
td=0x0)
at vnode_if.h:537
#13 0xc053fc71 in selscan (td=0xc3a56dc0, ibits=0xd38ceb9c,
obits=0xd38ceb8c,
nfd=6) at /usr/src/sys/sys/file.h:272
#14 0xc053f7df in kern_select (td=0xc3a56dc0, nd=6, fd_in=0xbfbfebc0,
fd_ou=0x0, fd_ex=0x0, tvp=0x0) at
/usr/src/sys/kern/sys_generic.c:816
#15 0xc053f446 in select (td=0x0, uap=0xd38ced14)
at /usr/src/sys/kern/sys_generic.c:720
#16 0xc068c700 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1, tf_esi =
134598312, tf_ebp = -1077941160, tf_isp =
ATAng problem: harddisk not detected
After yesterday's cvsup and kernel/world build my primary slave harddisk not longer gets detected (once again). If I revert to src/sys/dev/ata/ata-lowlevel.c 1.11 it is detected properly. (It might also work with later versions. If you need the exact revision where it stopped working please tell me) verbose dmesg can be found here http://stud4.tuwien.ac.at/~e0125637/dmesg.new verbose dmesg with ata-lowlevel.c 1.11 http://stud4.tuwien.ac.at/~e0125637/dmesg.old Stefan Ehmann ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ATAng problem: drive gets no longer detected
After tonight's cvsup and kernel build my primary slave hard disk gets no longer detected. This is due to the latest update to src/sys/dev/ata/ata-lowlevel.c. When i revert from version 1.10 to 1.9 everything is fine again. So much about the Hopefully this doesn't loose any real ATA disks... Relevant part of dmesg with ata-lowlevel.c 1.10: GEOM: create disk ad0 dp=0xc413d470 ad0: 58644MB IC35L060AVER07-0 [119150/16/63] at ata0-master UDMA66 acd0: CDRW CR-4804TE at ata1-master PIO3 acd1: DVDROM LITEON DVD-ROM LTD122 at ata1-slave PIO4 Relevant part of dmesg with ata-lovel.c 1.9 GEOM: create disk ad0 dp=0xc413d470 ad0: 58644MB IC35L060AVER07-0 [119150/16/63] at ata0-master UDMA66 GEOM: create disk ad1 dp=0xc413d270 ad1: 38166MB ST340823A [77545/16/63] at ata0-slave UDMA66 acd0: CDRW CR-4804TE at ata1-master PIO3 acd1: DVDROM LITEON DVD-ROM LTD122 at ata1-slave PIO4 Stefan Ehmann ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
