Re: odd behavior on select() after shutdown()
On Tue, May 18, 2010 at 12:58:05PM +0900, Yoshihiko Sarumaru wrote: Hi, 2010/5/18 Kostik Belousov kostik...@gmail.com: On Tue, May 18, 2010 at 01:08:50AM +0900, Yoshihiko Sarumaru wrote: Hi all, Select(2) has three arguments to get socket status for read, write and except. After upgrading to 8.0-RELEASE, select() after shutdown(SHUT_WR) returns with the status exceptfds is set. It means out-of-bound data can be read from the socket, but recv() with OOB flag returns ECONNRESET, and no packets with urgent flag was observed by tcpdump. It seems strange for me, but is it an intentional change on 8.x ? The patch below would fix the problem at hand. I am wondering what unintended consequences it might have. It works perfect for me on 8.0-RELEASE, thanks! I can't see how much this change has side effects, but is it commitable to current or stable? Kib, it seems you had changed some code using POLLHUP in uipc_socket.c. I'm not sure it is related to this issue, but could you give us your comments? Sometimes being kib, I have no further comments, except that I think that the behaviour you reported is consequence of Jeff and my changes. I intend to commit the patch tomorrow if nobody speaks up. We will see how it goes. pgpy08kTzkrLD.pgp Description: PGP signature
Re: *BSD meetup, London May 27th
On 16/05/2010 20:27, Owain Ainsworth wrote: On Sat, May 15, 2010 at 11:38:34PM +0100, Edd Barrett wrote: On Tue, May 11, 2010 at 1:44 PM, Sevan / Venture37 ventur...@gmail.com wrote: Hi Guys Some of us are meeting at the Barrowboy Banker by London bridge on the 27th this month, 7pm More details here: http://mailman.uk.freebsd.org/pipermail/ukfreebsd/2010-May/012735.html Sevan / Venture37 Anyone considering this? Sure, why not. -0- Yeah I'm hoping to ___ 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: Kernel panic when unpluggin AC adaptor
On Sat, May 15, 2010 at 9:12 PM, Brandon Gooch
jamesbrandongo...@gmail.com wrote:
On Thu, May 13, 2010 at 7:25 PM, Giovanni Trematerra
giovanni.tremate...@gmail.com wrote:
On Thu, May 13, 2010 at 1:09 AM, Brandon Gooch
jamesbrandongo...@gmail.com wrote:
On Wed, May 12, 2010 at 9:41 AM, Attilio Rao atti...@freebsd.org wrote:
2010/5/12 David DEMELIER demelier.da...@gmail.com:
I remove the patch, and built the kernel (I updated the src this
morning) and it does not panic now. It's really odd. If it reappears
soon I will tell you.
I looked at the code with Giovanni and I have the feeling that the
race with the idle thread may still be fatal.
We need to fix that.
Attilio
That seems to be the case, as my laptop shows about an 80-85 % chance
of experiencing a panic if left idle for long-ish periods of time (2
to 4 hours). I usually rebuild world or big ports overnight, and more
often than not I wake up to a panicked machine, same situation every
time:
...
rman_get_bushandle() at rman_get_bushandle+0x1
sched_idletd() at sched_idletd+0x123
fork_exit() at fork_exit+0x12a
fork_trampoline() at fork_trampoline+0xe
...
The kernel/userland is rebuilt, the ports are finished compiling --
it's in the time AFTER the completion of all tasks that the machine
gets bored and tries to kill itself :)
I have seen the AC adapter plug/unplug hang in the past on this
laptop, but I never made the connection between the events, as
nowadays my laptop usually stays plugged in :(
Attilio, I hope you can track this one down, let me know if I can do
anything to help or test...
Attilio and I came up with this patch. It seems ready for stress
testing and review
Please test and report back.
Thank you
P.S: all the faults are only mine.
I tried the patch, and my kernel panics I panic on boot. I have
8.5MB(!) of JPG images (6 of them) if anyone needs to see them. I'm
looking for a place to post them, but if anyone wants, I can send via
e-mail...
Hi Brandon,
Could you please, try this new one? The panic at boot stage should be solved,
at least I tried on a 8-way machine and all went ok at boot.
Please, remove WITNESS_SKIPSPIN from your kernel config file.
This patch might be sub-optimal and contains style(9) error but if it
works we are
on the right way.
Let me know if it works for you.
Thanks
--
Gianni
diff -r d7d0e04f42e3 sys/dev/acpica/acpi_cpu.c
--- a/sys/dev/acpica/acpi_cpu.c Wed May 12 04:01:56 2010 +0200
+++ b/sys/dev/acpica/acpi_cpu.c Mon May 17 09:21:25 2010 +0200
@@ -88,6 +88,8 @@ struct acpi_cpu_softc {
int cpu_cx_lowest;
charcpu_cx_supported[64];
int cpu_rid;
+ struct mtx cpu_lock;
+ int cpu_disable_idle;
};
struct acpi_cpu_device {
@@ -100,6 +102,10 @@ struct acpi_cpu_device {
#define CPU_SET_REG(reg, width, val) \
(bus_space_write_ ## width(rman_get_bustag((reg)),
\
rman_get_bushandle((reg)), 0, (val)))
+#define ACPI_CPU_LOCK(sc) \
+ mtx_lock_spin(sc-cpu_lock)
+#define ACPI_CPU_UNLOCK(sc) \
+ mtx_unlock_spin(sc-cpu_lock)
#define PM_USEC(x) ((x) 2) /* ~4 clocks per usec (3.57955 Mhz) */
@@ -127,7 +133,6 @@ static uint8_t cpu_cst_cnt; /* Indicat
static int cpu_quirks;/* Indicate any hardware bugs. */
/* Runtime state. */
-static int cpu_disable_idle; /* Disable entry to idle function */
static int cpu_cx_count; /* Number of valid Cx states */
/* Values for sysctl. */
@@ -284,6 +289,7 @@ acpi_cpu_attach(device_t dev)
ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
sc = device_get_softc(dev);
+ mtx_init(sc-cpu_lock, ntflck, NULL, MTX_SPIN);
sc-cpu_dev = dev;
sc-cpu_handle = acpi_get_handle(dev);
cpu_id = (int)(intptr_t)acpi_get_private(dev);
@@ -409,27 +415,30 @@ acpi_cpu_postattach(void *unused __unuse
SYSINIT(acpi_cpu, SI_SUB_CONFIGURE, SI_ORDER_MIDDLE,
acpi_cpu_postattach, NULL);
-/*
- * Disable any entry to the idle function during suspend and re-enable it
- * during resume.
- */
static int
acpi_cpu_suspend(device_t dev)
{
+struct acpi_cpu_softc *sc;
int error;
+sc = device_get_softc(dev);
error = bus_generic_suspend(dev);
if (error)
return (error);
-cpu_disable_idle = TRUE;
+ ACPI_CPU_LOCK(sc);
+sc-cpu_disable_idle = TRUE;
+ ACPI_CPU_UNLOCK(sc);
+
return (0);
}
static int
acpi_cpu_resume(device_t dev)
{
+struct acpi_cpu_softc *sc;
-cpu_disable_idle = FALSE;
+sc = device_get_softc(dev);
+sc-cpu_disable_idle = FALSE;
return (bus_generic_resume(dev));
}
@@ -523,16 +532,16 @@ acpi_cpu_shutdown(device_t dev)
{
ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+struct acpi_cpu_softc *sc;
+
+sc = device_get_softc(dev);
+
/* Allow
libdispatch : queue_kevent.c:204:20: use of undeclared identifier 'EV_RECEIPT'
Hey, i have followed the instruction emtioed in; http://wiki.freebsd.org/GCD but when i compiled libdispatch-r174 i got seven errors like; libdispatch : queue_kevent.c:204:20: use of undeclared identifier 'EV_RECEIPT' is there some bug in source code of libdisptch or freeBSD upgradation to 8.0 stable. for upgradation i have followed; http://www.freebsd.org/doc/en/books/handbook/makeworld.html to upgrade source code. please tell me how remove this bug. Thanks, Faiza ___ 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: *BSD meetup, London May 27th
Hi, Reference: From: Michal mic...@ionic.co.uk Date: Tue, 18 May 2010 10:50:01 +0100 Message-id: 4bf262c9.2040...@ionic.co.uk Michal wrote: On 16/05/2010 20:27, Owain Ainsworth wrote: On Sat, May 15, 2010 at 11:38:34PM +0100, Edd Barrett wrote: On Tue, May 11, 2010 at 1:44 PM, Sevan / Venture37 ventur...@gmail.com wrote: Hi Guys Some of us are meeting at the Barrowboy Banker by London bridge on the 27th this month, 7pm More details here: http://mailman.uk.freebsd.org/pipermail/ukfreebsd/2010-May/012735.html FYI these lists exist: freebsd-user-gro...@freebsd.org freebsd-us...@uk.freebsd.org manches...@bsdgroups.org.uk # I remembered a london group too, # but http: fails , whois bsdgroups.org.uk shows Sam Smith # as owner, nslookup shows dead server. Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML quoted-printable Base64 http://www.asciiribbon.org ___ 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: Give freeze a chance
On Mon, May 17, 2010 at 5:29 PM, Thomas Abthorpe tabtho...@freebsd.org wrote: The next wave of the challenge, fear, there is one more already composed to be released with 8.1! -- Give Freeze a chance with apologies to John Lennon et al Ev'rybody's talkin' 'bout portism, srcism, docism, cvsism, svnism, tagism This-ism, that-ism, ism ism ism All we are saying is give freeze a chance All we are saying is give freeze a chance C'mon Ev'rybody's talkin' 'bout re@, core@, doceng@, donations@, secteam@, marketing@, portmgr@, vendor-relations@ All we are saying is give freeze a chance All we are saying is give freeze a chance Let me tell you now Ev'rybody's talkin' 'bout Revolution, evolution, i18n, l10n, documentation, Integration, administration, applications, congratulations All we are saying is give freeze a chance All we are saying is give freeze a chance Ev'rybody's talkin' 'bout Erwin Lansing, Mark Linimon, Martin Wilke, Pav Lucistnik, Florent Thoumie, Ion-Mihai Tetcu, Kris Kennaway, Joe Marcus Clarke, Thomas Abthorpe too All we are saying is give freeze a chance All we are saying is give freeze a chance Nice, it makes me remember the old Breaking the Ports song... http://www.mail-archive.com/freebsd-po...@freebsd.org/msg02907.html -- Renato Botelho ___ 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
AHCI timeouts on S3 resume
A few months back, I swapped out my dying hard drive for a WD Scorpio Blue. Cheap, seemed reliable, and it was the only drive the local shop had in stock. However, it seems that AHCI doesn't like this device, and is having troubles during an S3 resume. It appears as though I'm experiencing two types of timeouts when resuming: recoverable, and non-recoverable. My question is: do I have a bad HDD, or is AHCI just not playing nicely? First off, if I try to resume when in graphics mode, it pretty much always fails (screen backlight comes on, but nothing else, system is non-responsive to all keypresses save ctrl+alt+del and a hard power down). I'm currently convinced this is because it's doing something that's triggering a non-recoverable timeout. However, when doing a suspend/resume from a text console, I can usually hit a recoverable timeout. Which looks like this (full suspend-resume cycle): - drm0: Mobile Intel\M-B\M-. GM45 Express Chipset on vgapci0 info: [drm] MSI enabled 1 message(s) vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xd000 256MB info: [drm] Initialized i915 1.6.0 20080730 drm0: [ITHREAD] switch from graphics to text; enter S3 sleep wlan0: link state changed to DOWN resume from S3 sleep ugen1.2: vendor 0x08ff at usbus1 (disconnected) ugen2.2: Chicony Electronics Co., Ltd. at usbus2 (disconnected) ugen1.2: vendor 0x08ff at usbus1 ugen1.3: Lenovo Computer Corp at usbus1 (disconnected) ugen2.2: Chicony Electronics Co., Ltd. at usbus2 ugen1.3: Lenovo Computer Corp at usbus1 wlan0: link state changed to UP ahcich0: Timeout on slot 24 ahcich0: is 00400040 cs 0f00 ss 0f00 rs 0ff0 tfd 80 serr 04050002 - Recovery from these timeouts seems to take 30s. However, periodically when resuming into text mode (and I assume what is almost always when resuming into graphics mode), I trigger a non-recoverable timeout: - ahcich0: Timeout on slot 13 ahcich0: is 0040 cs e000 ss e000 rs e00 tfd 80 serr 0405 ahcich0: device is not ready (timeout 15000ms) tfd = 0080 ahcich0: Timeout on slot 15 ahcich0: is 0040 cs e000 ss e000 rs 800 tfd 00 serr ahcich0: device is not ready (timeout 15000ms) tfd = (ada0:ahcich0:0:0:0): lost device ahcich0: Poll timeout on slot 15 ahcich0: is cs 8000 ss rs 800 tfd 00 serr GEOM_ELI: g_eli_read_done() failed ada0p3.eli[READ(offset=13067157504, length=65536)] GEOM_ELI: g_eli_read_done() failed ada0p3.eli[READ(offset=262144, length=8192)] GEOM_ELI: g_eli_read_done() failed ada0p3.eli[READ(offset=482927181824, length=8192)] GEOM_ELI: g_eli_read_done() failed ada0p3.eli[READ(offset=482927443968, length=8192)] ahcich0: Timeout on slot 15 ahcich0: is cs 00038000 ss 00038000 rs 0003800 tfd 00 serr ahcich0: devfice is not ready (timeout 15000ms) tfd = 0080 ahcich0: Poll timeout on slot 17 ahcich0: is cs 0002 ss rs 0002000 tfd 00 serr ahcich0: Timeout on slot 17 ahcich0: is cs 000e ss 000e rs 000e000 tfd 00 serr ahcich0: devfice is not ready (timeout 15000ms) tfd = 0080 - This continues, with the slot increasing by two every time. Each 'Timeout' and 'Poll timeout' takes ~15s to trigger, and I'd let this run to slot 23 before I powered down. The HDD is a WD Scorpio blue, model WD5000BEVT-22A0RT0, and isn't exactly the fastest drive on the planet. SMART seems to be relatively clean, with some mild questions surrounding attributes 191, 9/193, and 194: - ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051Pre-fail Always - 0 3 Spin_Up_Time0x0027 186 185 021Pre-fail Always - 1675 4 Start_Stop_Count0x0032 055 055 000Old_age Always - 45174 5 Reallocated_Sector_Ct 0x0033 200 200 140Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 200 200 000Old_age Always - 0 9 Power_On_Hours 0x0032 100 100 000Old_age Always - 723 10 Spin_Retry_Count0x0032 100 100 051Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 253 000Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000Old_age Always - 57 191 G-Sense_Error_Rate 0x0032 072 072 000Old_age Always - 28 192 Power-Off_Retract_Count 0x0032 200 200 000Old_age Always - 48 193 Load_Cycle_Count0x0032 162 162 000Old_age Always - 115712 194 Temperature_Celsius 0x0022 112 106 000Old_age Always - 35 196 Reallocated_Event_Count 0x0032 200 200 000Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200
Re: Kernel panic when unpluggin AC adaptor
On Tue, May 18, 2010 at 9:04 AM, Giovanni Trematerra giovanni.tremate...@gmail.com wrote: On Sat, May 15, 2010 at 9:12 PM, Brandon Gooch jamesbrandongo...@gmail.com wrote: On Thu, May 13, 2010 at 7:25 PM, Giovanni Trematerra giovanni.tremate...@gmail.com wrote: On Thu, May 13, 2010 at 1:09 AM, Brandon Gooch jamesbrandongo...@gmail.com wrote: On Wed, May 12, 2010 at 9:41 AM, Attilio Rao atti...@freebsd.org wrote: 2010/5/12 David DEMELIER demelier.da...@gmail.com: I remove the patch, and built the kernel (I updated the src this morning) and it does not panic now. It's really odd. If it reappears soon I will tell you. I looked at the code with Giovanni and I have the feeling that the race with the idle thread may still be fatal. We need to fix that. Attilio That seems to be the case, as my laptop shows about an 80-85 % chance of experiencing a panic if left idle for long-ish periods of time (2 to 4 hours). I usually rebuild world or big ports overnight, and more often than not I wake up to a panicked machine, same situation every time: ... rman_get_bushandle() at rman_get_bushandle+0x1 sched_idletd() at sched_idletd+0x123 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe ... The kernel/userland is rebuilt, the ports are finished compiling -- it's in the time AFTER the completion of all tasks that the machine gets bored and tries to kill itself :) I have seen the AC adapter plug/unplug hang in the past on this laptop, but I never made the connection between the events, as nowadays my laptop usually stays plugged in :( Attilio, I hope you can track this one down, let me know if I can do anything to help or test... Attilio and I came up with this patch. It seems ready for stress testing and review Please test and report back. Thank you P.S: all the faults are only mine. I tried the patch, and my kernel panics I panic on boot. I have 8.5MB(!) of JPG images (6 of them) if anyone needs to see them. I'm looking for a place to post them, but if anyone wants, I can send via e-mail... Hi Brandon, Could you please, try this new one? The panic at boot stage should be solved, at least I tried on a 8-way machine and all went ok at boot. Please, remove WITNESS_SKIPSPIN from your kernel config file. This patch might be sub-optimal and contains style(9) error but if it works we are on the right way. Let me know if it works for you. Applied the patch, built, installed, and booted new kernel: no panic! I will remove WITNESS_SKIPSPIN and build another kernel. Then I'll try to trigger the panic (by letting my laptop sit idle after a buildworld session). Thanks for giving this some attention, I hope you and/or others are able to get to the bottom of this... -Brandon ___ 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
