Bug 58193 – getc operations via RedBoot lock the system

Bug 58193 - getc operations via RedBoot lock the system

Summary:	getc operations via RedBoot lock the system

Status:	CLOSED WONTFIX

Aliases:	None

Product:	eCos
Classification:	Retired
Component:	HAL (Show other bugs)
Sub Component:
Version:	CVS
Hardware:	All Linux

Priority	low Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	eCos bugs internal list
QA Contact:	eCos bugs internal list
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2002-01-10 16:33 EST by Jonathan Larmour
Modified:	2007-03-26 23:50 EDT (History)
CC List:	0 users

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2003-06-20 12:11:02 EDT
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Jonathan Larmour 2002-01-10 16:33:21 EST

Description of Problem:

If someone does a getc operation that uses the virtual vectors to call into
redboot, then the system locks up and no other threads run because interrupts
are disabled and the scheduler is locked.

Instead hal_if_diag_read_char() should call a new CYGACC_COMM_IF_GETC_NONBLOCK
operation so that the looping to detect for a character is done with interrupts
enabled at least some of the time. Slower, but at least not stopped.

Comment 1 Jesper Skov 2002-01-11 01:57:41 EST

I disagree. If you use the polled routines provided by the VV, well, you'll
be polling. If you need an interrupt safe environment, use an IO driver.

Comment 2 Jonathan Larmour 2002-01-11 08:10:22 EST

I can't disagree with "If you need an interrupt safe environment, use an IO
driver.", but I don't see any harm in changing this behaviour (except arguably
bloat because we can't get rid of the non-block version now it's there).

Comment 3 Alex Schuilenburg 2003-06-20 12:11:02 EDT

This bug has moved to http://bugs.ecos.sourceware.org/show_bug.cgi?id=58193

Note You need to log in before you can comment on or make changes to this bug.